On Mon, Apr 23, 2012 at 12:19 PM, Stephen Hemminger <shemmin...@vyatta.com> wrote: > On Mon, 23 Apr 2012 15:15:33 -0400 (EDT) > David Miller <da...@davemloft.net> wrote: > >> From: Simon Horman <ho...@verge.net.au> >> Date: Mon, 23 Apr 2012 17:30:08 +0900 >> >> > I'm pretty sure the patch I posted added encap_rcv to tcp_sock. >> > Am I missing the point? >> >> It did, my eyes are failing me :-) >> >> > Currently I am setting up a listening socket. The Open vSwtich tunneling >> > code transmits skbs and using either dev_queue_xmit() or ip_local_out(). >> > I'm not sure that I have exercised the ip_local_out() case yet. >> >> I don't see where on transmit you're going to realize the primary >> stated benefit of STT, that being TSO/GSO. >> >> You'll probably want to gather as many packets as possible into a >> larger STT frame for this purpose. And when switching between STT >> tunnels, leave the packet alone since a GRO STT frame on receive will >> transparently become a STT GSO frame on transmit. >> > > I think the point of the TSO hack is to get around the MTU problem when > tunneling. > The added header of the tunnel eats into the the possible MTU. The use of TSO > in STT is designed to deal with the fact that hardware can't do IP > fragmentation > of IP (or UDP).
That is a beneficial side effect, although the main goal is to just to get back all of the offloads that are lost because hardware can't see inside of encapsulated packets, with TSO, LRO, and RSS being the main examples. Assuming that the TCP stack generates large TSO frames on transmit (which could be the local stack; something sent by a VM; or packets received, coalesced by GRO and then encapsulated by STT) then you can just prepend the STT header (possibly slightly adjusting things like requested MSS, number of segments, etc. slightly). After that it's possible to just output the resulting frame through the IP stack like all tunnels do today. Similarly, on the other side the NIC will be able to perform its normal offloading operations as well. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
