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  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:	Thu, 15 May 2008 21:58:23 -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 12:01:48 +1000

> Dave, please allow me to ask a heretical question.  Returning
> TX_BUSY has some appeal for virtio_net: is it fundamentally a flawed
> idea, or simply a matter of coding?

Allowing TX_BUSY adds a special case to the caller which we'd
like to remove at some point.

> Currently we have no virtio interface to ask how many descriptors are left; 
> it's not clear that it's a fair question to ask, since for Xen it's depends 
> on the actual buffers we're trying to put in the descirptors.

Two things:

1) You can always make sure that you have enough space for a
   TSO frame, with arbitrary page boundaries and thus buffer
   chopping.

   It can even be estimated, and if violated by some corner case
   you can punt and drop.

2) You can queue inside of the driver one packet when you hit
   the limits unexpectedly, netif_stop_queue(), and return
   success.  Spit this packet out right before waking the
   queue again.

Really, there are no hard reasons to ever return TX_BUSY,
it's always a bug.

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