netdev - Re: [PATCH 1/4] pch_gbe: Fix transmit queue management

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: <20131202.111600.1622488165507147936.davem@davemloft.net>
Date:	Mon, 02 Dec 2013 11:16:00 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	David.Laight@...LAB.COM
Cc:	puzman@...il.com, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/4] pch_gbe: Fix transmit queue management

From: "David Laight" <David.Laight@...LAB.COM>
Date: Mon, 2 Dec 2013 10:04:49 -0000

> I know you like ethernet drivers to work this way, but requiring enough
> descriptors for a maximally fragmented packet requires a difficult
> calculation and will cause the tx queue to be stopped unnecessarily.
 ...
> Isn't there also a new skb structure that allows lists of fragments?
> That might need even more descriptors for a worst case transmit.

Fragment lists are not to be found in the transmit function of the
driver.  Any such SKBs will be linearized or similar first.  We do
want to support them in some capacity in the future, but right now
we don't.

And here we're not talking about a USB driver, so using the rather
extreme example of the USB segmentation restrictions is not really
appropriate.

This is a pretty standard ethernet driver, which can use a one to
one correspondance between the segmentation count of the SKB and
the number of TX descriptors that will be used.

There is a large precedence for doing things this way and in this
particular case it's straightforward.
--
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