Re: [Tofoo] FW: I-D Action: draft-zhou-li-vxlan-soe-01.txt

Joe Touch <> Thu, 22 May 2014 18:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 904FD1A024B; Thu, 22 May 2014 11:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V_QvJWK99Xwj; Thu, 22 May 2014 11:17:06 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B5871A027E; Thu, 22 May 2014 11:17:06 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s4MIGZxM016425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 22 May 2014 11:16:36 -0700 (PDT)
Message-ID: <>
Date: Thu, 22 May 2014 11:16:35 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: "Zhou, Han" <>, "" <>, "" <>, "" <>, "" <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Cc: Erik Nordmark <>, Tom Herbert <>
Subject: Re: [Tofoo] FW: I-D Action: draft-zhou-li-vxlan-soe-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for Tunneling over Foo \(with\)in IP networks \(TOFOO\)." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 May 2014 18:17:07 -0000

On 5/21/2014 7:44 PM, Zhou, Han wrote:
> Hi Joe,
> Thanks for your explain, and in theory I tend to agree with you.
> However, look at the real world implementation of offload, e.g. Linux kernel, GSO is implemented in the way I described: a whole TCP packet (including headers and options) are generated by the TCP layer, and segmentation is performed as late as possible, depending on the FEATURES supported by net-device:
> 1) TSO is NOT supported by net-device then GSO software segmentation is performed (tcp_gso_segment())
> 2) TSO is supported by NIC, then segmentation is offloaded to NIC hardware. (in this case tcp_dump will not capture small packets but only the large packets before segmentation)
> 3) It is in Guest OS and TSO is supported by the virtual net-device, then segmentation is offloaded to host OS.
> And my change is specific for 3): without the change segmentation is performed according to the MSS specified by guest OS,  and with the change this segmentation is skipped.
> As you can see the compatibility problem you mentioned, if it is a real problem, is not introduced by my change.

Perhaps, but dealing with guest OS/TSO interactions could be designed as 
a correct example, rather than replicating the failure of other 

> Because of this, we might discuss it somewhere else, such as linux kernel community.
> I don't think current Linux kernel GSO implementation addresses the problem you mentioned (I could be wrong). Do you know any example of *correct* implementation of TCP offloading? Or it could be a TODO in linux kernel.

I haven't studied TSO implementations; there are too many, and many are