On Mon, Apr 09, 2012 at 09:30:43AM -0700, Jesse Gross wrote: > On Sun, Apr 8, 2012 at 10:39 PM, Simon Horman <ho...@verge.net.au> wrote: > > On Fri, Apr 06, 2012 at 10:44:18AM -0700, Jesse Gross wrote: > >> On Thu, Apr 5, 2012 at 7:10 PM, Simon Horman <ho...@verge.net.au> wrote: > >> > On Thu, Apr 05, 2012 at 05:34:21PM -0700, Jesse Gross wrote: > >> >> On Tue, Apr 3, 2012 at 10:14 PM, Simon Horman <ho...@verge.net.au> > >> >> wrote: > >> >> > The STT protocol's header includes a field for the offset > >> >> > to the start of the l4 header. It seems that this > >> >> > is the value of the transport_offset of the original SKB and > >> >> > making that value available to the update_header callback avoids > >> >> > STT needing to calculate the offset. > >> >> > > >> >> > Signed-off-by: Simon Horman <ho...@verge.net.au> > >> >> > >> >> Isn't it possible to quickly compute the L4 offset if you know the > >> >> size of the header (which in STT is fixed)? I'm just trying to > >> >> minimize the amount of protocol-specific code in the generic tunneling > >> >> code as we add more protocols. > >> > > >> > To be honest I'm not sure that I really understand the motivation for the > >> > l4_offset in STT. But it seems to me the difficulty in calculating > >> > l4_offset lies in calculating the size of the IP header in the inner > >> > packet, especially in the case of IPv6. I'm quite happy to accept that I > >> > have missed the point somehow. > >> > >> It is to be able to efficiently skip over the IP header on the receive > >> side. However, on the transmit side we already have computed this > >> information. What I'm suggesting is essentially the same as what you > >> have done here, just a slightly different implementation. I think the > >> L4 offset can be computed with the information that we already have by > >> doing: > >> > >> csum_start - (skb_headroom(skb) + skb_network_offset(skb) + > >> mutable->tunnel_hlen) > > > > I'm assuming this is skb->csum_start, however, it seems to be 0 > > when entering stt_update_head() when testing using an emulated > > interface with OVS running inside a KVM guest. > > > > I have also tested using a virtio interface, in which case > > the calculation above gives the correct result on occasions where > > csum_start is non-zero. > > I guess the draft is somewhat unclear on this but the field is only > required if some form of offloading is in use (either checksum or > segmentation). In the cases where there is no offloading or the > protocol being encapsulated is not one that can be offloaded the > l4_offset field should be zero and the checksum partial flag left > unset. We're really just trying to encode the value of the csum_start > field here in a host-independent manner.
Thanks, got it. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
