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 C5D9A1F5 for ; Wed, 17 Dec 2014 08:17:37 +0100 (CET) Received: by mail-wi0-f170.google.com with SMTP id bs8so15922164wib.5 for ; Tue, 16 Dec 2014 23:17:37 -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=TIQ4OqQoJsECws3VlpOAZRBMeqa9QWGr5xbe+I8fj44=; b=bxLCLn9ADOD2J0dsLq/EI361ixgnWL1Yg1g5zxYKgHlA8hnzg+smp1143WtWkup3Gj UXBhaKB+j9qrP8jZ/gJ5m2OdSIIu3AHY6RBMp1h/GIxfNDt9JYqK/src66/2/YgGhX8G wu8cTuRBF5xC4x6/wN9UPkvKwWvBJ6aiR4I1r+XflxVml2+9eV95X0Jiw7trWnce0yXA ED2IJql9gghW6Ptd+11Ss1617+UPQXEZKxQLAbl5n1yrST0mbAkkB6ooIdyzMOx/Wjt3 cjvIBW9pPKTJDx0l9ccF8HC2XKPStxF6miXJcZjqmkxSlK2TNqOYxaFr7zcrLHS228rT jQ/A== MIME-Version: 1.0 X-Received: by 10.180.210.228 with SMTP id mx4mr6842926wic.57.1418800657640; Tue, 16 Dec 2014 23:17:37 -0800 (PST) Received: by 10.194.64.9 with HTTP; Tue, 16 Dec 2014 23:17:37 -0800 (PST) In-Reply-To: References: Date: Wed, 17 Dec 2014 09:17:37 +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: Wed, 17 Dec 2014 07:17:37 -0000 thanks. i will check this On Tue, Dec 16, 2014 at 4:04 PM, Alex Markuze wrote: > > > > On Tue, Dec 16, 2014 at 2:24 PM, Helmut Sim wrote: >> >> Thanks Alex, >> >> So i probably miss something... >> what you are saying is correct for IP segmentation where the segmentation >> is at the IP level, and all segments are identified according to the >> Identification field in the IP header. >> >> However in TCP segmentation the segments are at the TCP level (isn't >> it?), where each frame is at a size of >> MSS+sizeof(tcp_hdr)+sizeof(ip_hdr)+sizeof(eth_hdr). >> Hence, for each of the sent packets, the IP Identification is 0 and the >> IP total length is MSS+sizeof(tcp_hdr)+sizeof(ip_hdr). >> >> Please correct me if i am wrong. >> > TSO - takes a one packet max size 64KB(not counting mac/vlan size). and > brakes it into valid mtu sized packets each with its one IP and TCP header. > I'm not sure what how the identificayion/Frag off fields are filled. you > can easily check it by running a short tcp stream(perf/netperf) between two > machines and capturing the packets with tcpdump (wireshark to open) use > ethanol -K to disable LRO/GRO (the receive side kernel driver will > rearrange the headers otherwise). > > I hope this helps. > >> >> > thanks. >> >> On Tue, Dec 16, 2014 at 11:10 AM, Alex Markuze wrote: >>> >>> >>> >>> On Mon, Dec 15, 2014 at 10:20 PM, Helmut Sim >>> wrote: >>>> >>>> Hi, >>>> >>>> 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. >>>> >>> >>> TSO segments a TCP packet into mtu sied bits. The TCP/IP protocols are >>> limited to 64K due to the length fields being 16bit wide. You can't build a >>> valid packet longer then 64K regardless of the NIC. >>> >>> >>>> 2. >>>> I wonder, Is there a specific reason why TSO is supported only for IXGBE >>>> and not for IGB ? the 82576 NIC supports TSO though. >>>> Is it due to a kind of tecnical barrier or is it because of priorities? >>>> >>>> It will be great if someone from the forum could address this. >>>> >>>> Thanks, >>>> Sim >>>> >>>