From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by dpdk.org (Postfix) with ESMTP id 558FD683A for ; Tue, 16 Dec 2014 15:04:48 +0100 (CET) Received: by mail-la0-f51.google.com with SMTP id ms9so11191572lab.24 for ; Tue, 16 Dec 2014 06:04:48 -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=1EnybEBfTCmpJQe+TSYxAKdjP3ZWtWuIv6tDG+JnZxQ=; b=hZggLl1sE4GbneSxhq9gifE9rr56hZhKZeC/Sfeb9t+beRuNL0mRNZsXoL0L+HqC++ qEEbuMDmPRVlXMKhU6wShl4dJIUI6UqediBR+EiEJAy56qOKPM6/Gu0QnYGziG1UZX0y V1TuYgGtXuGGZuymIqeGdOYN2JR4zg7n0mUoWwOImKxtOfFNlnoPWZi15MM0SZAMUbei o84LeT8FOUKveuw/NNDrZGVBqflMrkKsPPI3UZJ28MwgUqYh9bD8kM3ClRy8qvxpRQBw uunswK6lxX6u05WM1NmqFBYcoU7toPnw3r/OhpGCCoqrZqjYgWQi8UpImO+DzMPf94kF Ck3w== X-Gm-Message-State: ALoCoQnVwZHeX99588RcfCoME5MjlG2eRzEjZ2A/RTxSlaARhTeTXdrjFXMNB09/9cLAKOUCC5Sw MIME-Version: 1.0 X-Received: by 10.152.5.226 with SMTP id v2mr24830370lav.34.1418738688042; Tue, 16 Dec 2014 06:04:48 -0800 (PST) Received: by 10.25.215.208 with HTTP; Tue, 16 Dec 2014 06:04:47 -0800 (PST) In-Reply-To: References: Date: Tue, 16 Dec 2014 16:04:47 +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: Tue, 16 Dec 2014 14:04:48 -0000 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 >>> >>