From owner-svn-src-head@freebsd.org  Tue Sep 15 11:15:09 2015
Return-Path: <owner-svn-src-head@freebsd.org>
Delivered-To: svn-src-head@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id A406CA0433E;
 Tue, 15 Sep 2015 11:15:09 +0000 (UTC) (envelope-from hps@selasky.org)
Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 645F31078;
 Tue, 15 Sep 2015 11:15:09 +0000 (UTC) (envelope-from hps@selasky.org)
Received: from laptop015.home.selasky.org
 (cm-176.74.213.204.customer.telag.net [176.74.213.204])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.turbocat.net (Postfix) with ESMTPSA id 663D81FE023;
 Tue, 15 Sep 2015 13:15:07 +0200 (CEST)
Subject: Re: svn commit: r271946 - in head/sys: dev/oce dev/vmware/vmxnet3
 dev/xen/netfront kern net netinet ofed/drivers/net/mlx4 sys
To: Adrian Chadd <adrian.chadd@gmail.com>,
 =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <royger@freebsd.org>
References: <201409220827.s8M8RRHB031526@svn.freebsd.org>
 <55F69093.5050807@FreeBSD.org> <55F6935C.9000000@selasky.org>
 <55F6A694.7020404@FreeBSD.org> <55F6A914.6050109@selasky.org>
 <55F6ED8F.5030402@FreeBSD.org>
 <CAJ-Vmo=vq6NbUNecTvkzDLQW3rQzpPToFGbR9TxdcyO_BL3s_g@mail.gmail.com>
Cc: "src-committers@freebsd.org" <src-committers@freebsd.org>,
 "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>,
 "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>
From: Hans Petter Selasky <hps@selasky.org>
Message-ID: <55F7FE1A.3050500@selasky.org>
Date: Tue, 15 Sep 2015 13:16:42 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAJ-Vmo=vq6NbUNecTvkzDLQW3rQzpPToFGbR9TxdcyO_BL3s_g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-BeenThere: svn-src-head@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: SVN commit messages for the src tree for head/-current
 <svn-src-head.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-head>,
 <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/>
List-Post: <mailto:svn-src-head@freebsd.org>
List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-head>,
 <mailto:svn-src-head-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Sep 2015 11:15:09 -0000

On 09/14/15 20:35, Adrian Chadd wrote:
> Hi,
>
> So what's the actual behaviour of the new tso logic before and after
> the above change in tsomax?

Hi,

The behaviour is the same, only the limits have changed a bit.

 > like, what are the actual packet sizes
> being sent up to the hardware?

It is not about the packet sizes, it is about the number of packets we 
transmit per TSO block.

> Is TSO or the TCP stack so fragile that
> a slight change in how packets are broken up results in ridiculously
> less throughput? It's only a few bytes.

Network adapters which support TSO typically has a hard limit on the 
number of mbufs it can load. When we exceed this limit, m_defrag() or 
packet drop is next. It is the responsibility of the TCP stack to 
generated mbuf chains which are within the network adapter given limits. 
Previously only the length was accounted for. Now we also account for 
the number of segments, because there are many ways a 64K bytes long 
mbuf chain can be generated.

--HPS