From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by dpdk.org (Postfix) with ESMTP id 1A8055A06 for ; Sun, 4 Jan 2015 10:57:54 +0100 (CET) Received: by mail-lb0-f181.google.com with SMTP id l4so16860778lbv.12 for ; Sun, 04 Jan 2015 01:57:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qRro0TFuhakj/N1a1QOtDcW6sgUONs+KBINR6QdflZU=; b=PfnHGnfNl3W5/rXtRlBvX3gACWOjF970x4xTrMd9p6PWUXQDCc6PsPQSf4V2aGp6SV fO24pFkWZ6BwBioNl7VqfXnLw+6F9UoeO08Bes6nArbZBSaktUog3QVg6TV5lcFIEZNj i5cVxnSjCc7zVqzJ1bvTWCUVzL9HLIxF3UcGTDfTqWJiHV34aKbynqBea7u+PjF/YlGj ROat+AcqgWfpwHpDVo8CqM/TGnemqMVbUqmhJQMrxATtyx6Kbb1xglzrAyNFX5wjrG/V OSdqO3x90EYOB9mUqpW790tgdwUPaQtFQ2vp5DP+7E5b45GG8+PR+XL9nBGSr4nzhehQ CohQ== X-Gm-Message-State: ALoCoQmWKshNy+ksKAJb6FY7qb+ZzrH8Mn9x02C8t0PiivYL8qAM7Zm7sesm5f4Vvv5FxYObr4Hk MIME-Version: 1.0 X-Received: by 10.152.7.229 with SMTP id m5mr86614602laa.80.1420365473771; Sun, 04 Jan 2015 01:57:53 -0800 (PST) Received: by 10.25.215.208 with HTTP; Sun, 4 Jan 2015 01:57:53 -0800 (PST) In-Reply-To: References: <54917ECB.3080404@6wind.com> Date: Sun, 4 Jan 2015 11:57:53 +0200 Message-ID: From: Alex Markuze To: Helmut Sim 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 09:57:54 -0000 On Sun, Jan 4, 2015 at 10:50 AM, Helmut Sim wrote: > 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. > Oliver thanks for reporting back, this is interesting but doesn't come as a surprise as the headers must be correct when on the wire, what I couldn't tell you is what happens with the identificayion/Frag off fields. The IP length limitation comes from the send side network stack, theoreticaly Its possible to send a packet of any size as long as your network stack doesn't mind sending a packet with a malformed IP header(as the length field is not defined). . The send side HW recieves a single packet with the ip length of the whole packet. Assuming that the ixgbe HW takes the packet len for its TSO fragmentation from the TX descriptor rather then from the IP header, it should be able to send as much as the HW supports. > 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 >> >> >