netdev - Re: [PATCH] mac80211: rewrite fragmentation code

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] [day] [month] [year] [list]

Message-Id: <20080519.000328.16713955.davem@davemloft.net>
Date:	Mon, 19 May 2008 00:03:28 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	rusty@...tcorp.com.au
Cc:	herbert@...dor.apana.org.au, mb@...sch.de,
	johannes@...solutions.net, linux-wireless@...r.kernel.org,
	netdev@...r.kernel.org, ron.rindjunsky@...el.com, tomasw@...il.com,
	ivdoorn@...il.com, peter.p.waskiewicz.jr@...el.com
Subject: Re: [PATCH] mac80211: rewrite fragmentation code

From: Rusty Russell <rusty@...tcorp.com.au>
Date: Mon, 19 May 2008 13:08:13 +1000

> The bit I can't see is what to do about qdisc if the driver manages its own 
> queue(s).  Leave the qdisc as currently in place and have the driver call 
> dev_dequeue_skb() (or some wrapper) directly?  Modulo locking issues, that 
> should be a fairly simple change.

I'd like to approach a state where the device is just a black hole
that the qdisc injects packets into.  At least theoretically, that's
what the network is once the packet leaves the device anyways.  Nobody
really notices as long as flows don't get reordered.

I realize it isn't feasible to retain many of the qualities that some
qdiscs want (rates, qfull handling, etc.), so we'll have to provide
some handling for that, ideally in some cheap slowpath test.

But for things like tx queue backlog overflow the behavior would
be essentially the same.  The only change is that the txqueuelen
parameter is handled inside of the driver (again, perhaps via
helpers).

Our TX path is way too complicated and, frankly, restrictive.

This is why we don't have real parallel TX multiqueue support as a
simple patch to some drivers.  We have fundamental restrictions that
keep that from happening.
--
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