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]
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

Powered by blists - more mailing lists