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) The best way to think about the fields in the STT header is as an encoding of information in the skb metadata or the transmit descriptors passed to the NIC. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
