Hi Jeremy,
> > My guess would be the change from
> > CHECKSUM_{HW,etc}+skb->proto_{csum,data}_valid to
> > CHECKSUM_{UNNECESSARY,PARTIAL,etc} is incomplete/incorrect. This should
> > be taken care of by f4f969ffe1d9326ccaace768bde3b33a5ae49e71. I saw
> > checksum offloading issues early on when I did this but I thought I got
> > it right eventually, I'm pretty certain it was OK for me at the time at
> > least.
> >
>
> It looks like the checksum is a secondary issue. My understanding is
> that things like TSO, USO, LRO, etc, depend on hardware checksumming, so
> disabling checksumming will implicitly disable the large segment
> features too. And judging from Christophe's report, it seems that's the
> issue, with unexpectedly large packets appearing in dom0.
The checksum offloading is fine, I've checked this in a couple of
different ways. What I find strange, is that with TSO packets should be
chopped on their way out (in software, if the hardware doesn't support
it). I am wondering who is sending the "fragmentation needed" reply in
the Dom0 network stack.
ip_forward.c for instance has something like this:
if (unlikely(skb->len > dst_mtu(&rt->u.dst) && !skb_is_gso(skb) &&
(ip_hdr(skb)->frag_off & htons(IP_DF))) && !skb->local_df)
IP_INC_STATS(dev_net(rt->u.dst.dev), IPSTATS_MIB_FRAGFAILS);
icmp_send(skb, ICMP_DEST_UNREACH, ICMP_FRAG_NEEDED,
htonl(dst_mtu(&rt->u.dst)));
goto drop;
}
So if the packet is *marked* as being segmentation offloaded it should
be passed to the NIC driver where it's handled. At least that is my
understanding. Turning on gso/tso support on the outgoing NIC doesn't
make a difference.
It seems that netfront/netback make sure that the GSO bits are passed on
correctly, but I would need to inspect the skbuff's in Dom0 to find out
if this is working correctly. Because if the GSO bits in skbuff was for
some reason missing, it would explain the behaviour I am seeing. Or, of
course, there's something else I am missing.
Christophe
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home