netdev - RE: [PATCH] [NET 2.6.26]: Add per-connection option to set max TSOframe size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <D5C1322C3E673F459512FB59E0DDC329049C4342@orsmsx414.amr.corp.intel.com>
Date:	Fri, 29 Feb 2008 15:20:20 -0800
From:	"Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
To:	"Jarek Poplawski" <jarkao2@...il.com>
Cc:	<davem@...emloft.net>, <stephen.hemminger@...tta.com>,
	<netdev@...r.kernel.org>
Subject: RE: [PATCH] [NET 2.6.26]: Add per-connection option to set max TSOframe   size

> > +++ b/include/linux/netdevice.h
> ...
> > +	/* for setting kernel sock attribute on TCP connection setup */
> > +#define GSO_MAX_SIZE		65536
> > +	u32			gso_max_size;
> 
> One more, maybe foolish, thrifty idea: do we really need such 
> a precision here? I don't know those devices, but maybe it 
> would be enough (for the beginning at least?) to use a few 
> divisors e.g.:
> 
> gso_max_size = 65536 >> GSO_MAX_SIZE_SHIFT
> 
> Then it seems 3 or 4 bits should be enough for this, and BTW, 
> it looks like dev->features has 16 bits for various GSO 
> flags, with "a lot" of free space yet - unless I missed something?

This patch has two purposes, one to add an additional tunable for TSO
for drivers, and two, to support buggy hardware that can do segmentation
offloading, but can't handle 64 KB frames.  Your suggestion here would
lend well for the latter, for drivers needing to set the maximum frame
size to something "smaller," and not really needing or wanting fine
granularity.  It just needs something smaller to chew on vs. the current
64 KB frames.

For the tuning, I see the desire for something much more granular.
Looking ahead at some of the giant send offload features coming (support
for TSOs bigger than 64 KB) and even for current adapters looking to
fine tune TSO given a certain workload, I see the need for this
granularity.  For a certain type of workload, a TSO max frame size of 40
KB, or 20 KB, or even 50 KB might be something a driver would like to
do.

Hopefully this clarifies my intent.  I think keeping the full precision
is the right thing to do moving forward.  I really do appreciate the
inputs though, keep them coming please.  :-)

Cheers,
-PJ Waskiewicz
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html