From owner-freebsd-current@FreeBSD.ORG  Mon Jul  7 08:11:58 2014
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by hub.freebsd.org (Postfix) with ESMTPS id ACC72271;
 Mon,  7 Jul 2014 08:11:58 +0000 (UTC)
Received: from mail.turbocat.net (mail.turbocat.net
 [IPv6:2a01:4f8:d16:4514::2])
 (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 6FEE5270E;
 Mon,  7 Jul 2014 08:11:58 +0000 (UTC)
Received: from laptop015.home.selasky.org
 (cm-176.74.213.204.customer.telag.net [176.74.213.204])
 (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 by mail.turbocat.net (Postfix) with ESMTPSA id E5CED1FE02D;
 Mon,  7 Jul 2014 10:11:56 +0200 (CEST)
Message-ID: <53BA5657.8010309@selasky.org>
Date: Mon, 07 Jul 2014 10:12:07 +0200
From: Hans Petter Selasky <hps@selasky.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: freebsd-net@freebsd.org, freebsd-current@FreeBSD.org
Subject: [RFC] Allow m_dup() to use JUMBO clusters
Content-Type: multipart/mixed; boundary="------------030007040205090607060001"
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jul 2014 08:11:58 -0000

This is a multi-part message in MIME format.
--------------030007040205090607060001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I'm asking for some input on the attached m_dup() patch, so that 
existing functionality or dependencies are not broken. The background 
for the change is to allow m_dup() to defrag long mbuf chains that 
doesn't fit into a specific hardware's scatter gather entries, typically 
when doing TSO.

In my case the HW limit is 16 entries of length 4K for doing a 64KByte 
TSO packet. Currently m_dup() is at best producing 32 entries of each 2K 
for a 64Kbytes TSO packet.

By allowing m_dup() to get JUMBO clusters when allocating mbufs, we 
avoid creating a new function, specific to the hardware, to defrag some 
rare-occurring very long mbuf chains into a mbuf chain below 16 entries.

Any comments?

--HPS


--------------030007040205090607060001
Content-Type: text/x-patch;
 name="uipc_mbuf.c.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="uipc_mbuf.c.diff"

=== uipc_mbuf.c
==================================================================
--- uipc_mbuf.c	(revision 268358)
+++ uipc_mbuf.c	(local)
@@ -917,7 +917,15 @@
 		struct mbuf *n;
 
 		/* Get the next new mbuf */
-		if (remain >= MINCLSIZE) {
+		if (remain >= MJUM16BYTES) {
+			/*
+			 * By allocating a bigger mbuf, we get fewer
+			 * scatter gather entries for the hardware to
+			 * process:
+			 */
+			n = m_getjcl(how, m->m_type, 0, MJUM16BYTES);
+			nsize = MJUM16BYTES;
+		} else if (remain >= MINCLSIZE) {
 			n = m_getcl(how, m->m_type, 0);
 			nsize = MCLBYTES;
 		} else {

--------------030007040205090607060001--