netdev - Re: [RFC v4] Add TCP encap

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAEP_g=_3om5aR=P0ffa9421KhvYYrMEeE33TNcCC9UV6+XVWAQ@mail.gmail.com>
Date:	Mon, 23 Apr 2012 13:08:49 -0700
From:	Jesse Gross <jesse@...ira.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	David Miller <davem@...emloft.net>, 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, Apr 23, 2012 at 12:19 PM, Stephen Hemminger
<shemminger@...tta.com> wrote:
> 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).

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.
--
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