From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by dpdk.org (Postfix) with ESMTP id 72F95593A for ; Sun, 4 Jan 2015 11:13:35 +0100 (CET) Received: by mail-wi0-f170.google.com with SMTP id bs8so2563783wib.3 for ; Sun, 04 Jan 2015 02:13:34 -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=CyMvoJFWAAo/aHsy8Bl7kF3bkkDy459tGEc55fWBqWg=; b=uaHnJiHW2HqucdANkvF6NpO21QePHM8tzSDYcMZWoMGPK9NJmCjaneqwRxZAmK0UNH 5cE8O0VJvRNQQb6JbdYc/GaQFM9Gd9CxG5ZFWzyAFH3/iVsZbYDN8Qs9Qb9nHHG0lu4/ nwapDAEVulUuEiU3FNGfjJckmXuixRICdEE4WBaQ+hdTjEwoOxXKNDcQYBOlPr5+GOGR fNqp6dPwfEtWyzaOBSb7ZDHNh/xZWzUQJolZ40qbIfeCWZvfMkQosK62fkBvOR+ADQa4 cc4m3/3JoLu8RNqONibEiP5STHqrdTvctmKQDPNzDHS0HJuyao8u5n+HfxTBips22SQf fkdQ== MIME-Version: 1.0 X-Received: by 10.180.13.7 with SMTP id d7mr14628018wic.57.1420366414243; Sun, 04 Jan 2015 02:13:34 -0800 (PST) Received: by 10.194.137.129 with HTTP; Sun, 4 Jan 2015 02:13:34 -0800 (PST) In-Reply-To: References: <54917ECB.3080404@6wind.com> Date: Sun, 4 Jan 2015 12:13:34 +0200 Message-ID: From: Helmut Sim To: Alex Markuze 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 10:13:35 -0000 correct. 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). Sim On Sun, Jan 4, 2015 at 11:57 AM, Alex Markuze wrote: > > > 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 >>> >>> >> >