From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <olivier.matz@6wind.com>
Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67])
 by dpdk.org (Postfix) with ESMTP id DB18B5938
 for <dev@dpdk.org>; Mon,  5 Jan 2015 09:53:31 +0100 (CET)
Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214]
 helo=[192.168.0.10])
 by mail.droids-corp.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128)
 (Exim 4.80) (envelope-from <olivier.matz@6wind.com>)
 id 1Y83Sz-0002Nj-0k; Mon, 05 Jan 2015 09:57:02 +0100
Message-ID: <54AA50F8.2070305@6wind.com>
Date: Mon, 05 Jan 2015 09:53:12 +0100
From: Olivier MATZ <olivier.matz@6wind.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.3.0
MIME-Version: 1.0
To: Helmut Sim <simhelmut@gmail.com>, Alex Markuze <alex@weka.io>
References: <CAF8yGaERQQ6DGPOotsJcXWuEzF=otRyA_ei7nffy8-bfZGWdNQ@mail.gmail.com>	<CAKfHP0WY8n1tyxw7jbeBU2EgrAziyv+1h+xAuLyQ7Uu9AgiSzw@mail.gmail.com>	<CAF8yGaFO+VXnvh1Er=oWUPrbGqc46fJdCp7Wez3gNgcjLCdqZw@mail.gmail.com>	<CAKfHP0XNNqOSGsZ4zVn3va5f+fxRsZCP=YVdXpUx=eYTVO8xhw@mail.gmail.com>	<CAF8yGaGSZgGrO19AKFxsP+Oq6rLmoYvmVBmsyes+QfXT2E6vJw@mail.gmail.com>	<54917ECB.3080404@6wind.com>	<CAF8yGaEBVYRzWWDmmfxP7mG-o+oz8_ciDm+pSUoAWpBycjCObw@mail.gmail.com>	<CAKfHP0W3jLTQeTvyKtUgKd0sVVDo1SA5coY=YgvqQpr6BDfNEA@mail.gmail.com>
 <CAF8yGaHydSrgF7aWcXGy=AbmmpMKVmrjuqDtazFoeh6TRW+y0w@mail.gmail.com>
In-Reply-To: <CAF8yGaHydSrgF7aWcXGy=AbmmpMKVmrjuqDtazFoeh6TRW+y0w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] two tso related questions
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jan 2015 08:53:32 -0000

Hi,

On 01/04/2015 11:13 AM, Helmut Sim wrote:
> In such case, a modified api should not require to set the ip_hdr
> total_length field, which is 16 bits.
> The HW will assign the correct packet length for each transmitted IP
> packet which is l3_len+l4_len+mss (except of the last segment which may
> be smaller than mss).
> [...]
>         I went over the 82599 datasheet and as Olivier mentioned it is a
>         18 bits field, hence allowing up to 256KB length.
> 
>         Olivier, although tcp window size field is 16 bits the
>         advertised window is typically higher than 64KB using the TCP
>         window scaling option (which is the common usage today).
> 
>         Hence I think that the API should allow at least up to 256KB
>         packet length, while finding a solution to make sure it also
>         support lower lengths for other NICs.


I don't think that the maximum TSO packet should be bigger than
what we have. TSO does not exempt to implement a TCP stack, and
it is not designed to send megabytes of data without the intervention
of the TCP stack.

The objective is to accelerate the segmentation of packets. Indeed,
without TSO, the main costs are the segmentation itself (usually
at ~1.5K) and the fact that each 1.5K packet go through the low
layer code (driver).

TSO solves these 2 problems even with a length limit at 64K: it
would represent ~40 times less packets to segment and transmit to
the driver, dividing the cost by the same amount. I think increasing
the max length won't make any difference in terms of performance.

Regards,
Olivier