From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by dpdk.org (Postfix) with ESMTP id E1FED5952 for ; Sun, 4 Jan 2015 09:50:13 +0100 (CET) Received: by mail-we0-f170.google.com with SMTP id w61so6352532wes.29 for ; Sun, 04 Jan 2015 00:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t8UhuU2ubufezUtjVwpt4xkAy/xlACirhhLQb7AfMe4=; b=jjfMHKkca8a1opuPWxmGOCUf70R37/2yH/9hi068XrbER20ynneMP8lXlauQxq69LY 3a/5VOcYlh7Afeh6HYPHN6662a+es2s5i1vjDPH5n1bv2I3lZUWLQtSPWmr6YQpFnS5+ 1R13QlsnMccTUOl53Uh0eBr8NG8cqvf4wxk4ZJ2JKaWOofucO/X/ufV4Xi5jPmhFcIll 005dbVBQI/cke3nUtaNYPs6La1mrk/7T3aOalixv4LbabcsyeRA5Brn/HoN7wktlzQVK fPQ+S7zlZtUEJVd1vvgggOyu9YpFGkcapq6VbYwvtOCWjBjdGfk4TNGkFasEOQ58pDu/ kp6g== MIME-Version: 1.0 X-Received: by 10.180.228.72 with SMTP id sg8mr14188623wic.48.1420361413789; Sun, 04 Jan 2015 00:50:13 -0800 (PST) Received: by 10.194.137.129 with HTTP; Sun, 4 Jan 2015 00:50:13 -0800 (PST) In-Reply-To: <54917ECB.3080404@6wind.com> References: <54917ECB.3080404@6wind.com> Date: Sun, 4 Jan 2015 10:50:13 +0200 Message-ID: From: Helmut Sim To: Olivier MATZ Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 08:50:14 -0000 Hi Alex and Olivier, Alex, I made the test and the segmentation is not at the IP level (i.e. each packet ip total length indicated the mss length), hence the 16 bits total length limitation is not relevant here. 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. Any idea? Sim On Wed, Dec 17, 2014 at 3:02 PM, Olivier MATZ wrote: > Hi Helmut, > > On 12/17/2014 08:17 AM, Helmut Sim wrote: > >> While working on TSO based solution I faced the following two questions: >>>>>> >>>>>> 1. >>>>>> is there a maximum pkt_len to be used with TSO?, e.g. let's say if >>>>>> seg_sz >>>>>> is 1400 can the entire segmented pkt be 256K (higer than 64K) ?, then >>>>>> the >>>>>> driver gets a list of chanined mbufs while the first mbuf is set to >>>>>> TSO >>>>>> offload. >>>>>> >>>>> > I think the limitations depend on: > > - the window size advertised by the peer: your stack should handle this > and not generate more packets that what the peer can receive > > - the driver: on ixgbe, the maximum payload length is 2^18. I don't know > if there is a limitation on number of chained descriptors. > > I think we should define a way to know this limitation in the API. Maybe > a comment saying that the TSO length should not be higher than 256KB (or > fix it to 64KB in case future drivers do not support 256KB) is enough. > > Regards, > Olivier > >