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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
