[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120423121934.195e898c@nehalam.linuxnetplumber.net>
Date: Mon, 23 Apr 2012 12:19:34 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: David Miller <davem@...emloft.net>
Cc: horms@...ge.net.au, jhs@...atatu.com, stephen.hemminger@...tta.com,
netdev@...r.kernel.org, dev@...nvswitch.org, eric.dumazet@...il.com
Subject: Re: [RFC v4] Add TCP encap_rcv hook (repost)
On Mon, 23 Apr 2012 15:15:33 -0400 (EDT)
David Miller <davem@...emloft.net> wrote:
> From: Simon Horman <horms@...ge.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).
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists