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

Message-Id: <20080516.124039.253626477.davem@davemloft.net>
Date:	Fri, 16 May 2008 12:40:39 -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: Fri, 16 May 2008 20:32:48 +1000

> On Friday 16 May 2008 14:58:23 David Miller wrote:
> > In fact, I want to move things more and more towards the driver
> > queueing TX packets internally instead of the networking mid-layer.
> >
> > That will ahve benefits for things like TX multiqueue, we won't
> > need any locking at all, nor have any knowledge about multiple
> > queues at all, if the driver takes care of providing the buffer
> > between what the kernel gives it and what the device can handle
> > at the moment.
> 
> That would be great: then I could shove the packet back on the queue myself 
> and not have to ask you about it.  It's adding a *second* queue inside the 
> driver which feels terribly ugly...

My description describes how I want the mid-layer queue to disappear
entirely.  Queueing would be done by the driver only.

Only the driver knows all of these details about how much space there
is, what packet chopping has to take place and what effects that has
on queue space, multiqueue configurations, how one wants to hash to
multiple queues, how to lock this stuff the most efficiently.

The kernel should just get out of the way and let the driver take care
of everything.

Sure, we can have some standard helpers to deal with the most common
cases.  But anything non-trivial right now is painful because the
mid-layer model tries to be too helpful when it should just get out
of the way.
--
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