From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alex@weka.io>
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com
 [209.85.215.53]) by dpdk.org (Postfix) with ESMTP id 1EFB0959
 for <dev@dpdk.org>; Tue, 16 Dec 2014 10:10:36 +0100 (CET)
Received: by mail-la0-f53.google.com with SMTP id gm9so10639128lab.40
 for <dev@dpdk.org>; Tue, 16 Dec 2014 01:10:35 -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=oa/wGTnceSwkeA+dj5UfrrAfFdqTBDZUbbdQyVuiuG4=;
 b=hG/BbA1n0satME/B6tXK4BXm4NXDCdVLjkIFpE3B7u1xAYb0SJQuH+d1g13dYV1G1J
 YCmpIzSoiXI4Fmn1U8+WM7yrvMjQyl9XgJ4c/K63LiGMKc45OuNPzGlDTxQmrMyEJ9d8
 3oUxZ6tIN+G8pNVQtjjHBZ3sVva3RgNK1SqSvaIK5IO1feXb/CuHnMDrx7mWBhjxgDbz
 kUy0R3GLorJd39hbqGbcZeTkYS7Al3oDLX5avjIyxiqeMfdm6vlBesHafvcosmz0tQk4
 qQwBs95tXxjWHhKgW1s5uKaX4edUmUrjCSIzXvKA8enoE6kauyrCPp68KJKEm6TLHHkm
 MpUQ==
X-Gm-Message-State: ALoCoQloBMuXakgUTGXLtC6lL5fGmsPBut6LmkkHknCC+q2/LW9iUwfuleuZxGw9WzXt7MdOF4CA
MIME-Version: 1.0
X-Received: by 10.152.5.226 with SMTP id v2mr23580709lav.34.1418721035753;
 Tue, 16 Dec 2014 01:10:35 -0800 (PST)
Received: by 10.25.215.208 with HTTP; Tue, 16 Dec 2014 01:10:35 -0800 (PST)
In-Reply-To: <CAF8yGaERQQ6DGPOotsJcXWuEzF=otRyA_ei7nffy8-bfZGWdNQ@mail.gmail.com>
References: <CAF8yGaERQQ6DGPOotsJcXWuEzF=otRyA_ei7nffy8-bfZGWdNQ@mail.gmail.com>
Date: Tue, 16 Dec 2014 11:10:35 +0200
Message-ID: <CAKfHP0WY8n1tyxw7jbeBU2EgrAziyv+1h+xAuLyQ7Uu9AgiSzw@mail.gmail.com>
From: Alex Markuze <alex@weka.io>
To: Helmut Sim <simhelmut@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Cc: "dev@dpdk.org" <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 <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Dec 2014 09:10:36 -0000

On Mon, Dec 15, 2014 at 10:20 PM, Helmut Sim <simhelmut@gmail.com> 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
>