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: <20080515.215823.28841530.davem@davemloft.net>
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