On Wednesday 25 May 2005 04:40 pm, Keir Fraser wrote:
> On 25 May 2005, at 22:35, Jon Mason wrote:
> > The problem with the bridge device is that all traffic generated in
> > dom0 will
> > be software checksummed, regardless of whether it needs to be or not.
> > In
> > Xen's case, it will software checksum all traffic to domU, even though
> > the
> > vif device is advertising NETIF_F_NO_CSUM.
> >
> > This is because the stack doesn't see the features of the children
> > devices of
> > the bridge, only the features of the bridge device itself. I created
> > a quick
> > hack to work around this, and started the discussion on the Linux
> > netdev
> > mailing list about how to fix the problem. From this discussion, a
> > patch was
> > created which does most of what we want, but needs to be slightly
> > modified to
> > be optimal for Xen. I will post the Xen optimized patch as soon as I
> > have it
> > done.
>
> But we no longer bring up an IP interface on the bridge device -- we
> use veth0 instead, which advertises NETIF_F_IP_CSUM.
The bridge device still is the device that the stack sees, and uses its
features to determine what to do during transmission. If you monitor the
skb->ip_summed flag going into netif_be_start_xmit(), you will see that it is
0 (meaning that the stack did the checksum in software). Now if you add the
following patch to the bridging device, you will notice that ip_summed is now
being used.
--- net/bridge/br_device.c.orig 2005-05-13 11:23:02.552751024 -0500
+++ net/bridge/br_device.c 2005-05-13 11:25:39.155943720 -0500
@@ -101,4 +101,5 @@ void br_dev_setup(struct net_device *dev
dev->tx_queue_len = 0;
dev->set_mac_address = NULL;
dev->priv_flags = IFF_EBRIDGE;
+ dev->features = NETIF_F_HW_CSUM | NETIF_F_SG;
}
This patch oversimplifies what needs to be done, but it provides the general
idea and speedup that we are looking for.
Thanks,
Jon
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home