On Tue, 18 Jul 2006 20:07:34 -0700, Simon Barber wrote:

I have been thinking about a slightly different approach for the master
device. Since the master device represents the physical hardware, I am
thinking that the hardware driver could register the master device
directly itself. It would use the normal netdev_register call to do so.

How will you allocate structures for 802.11 specific data? You will
require the driver to call some ieee80211_allocate function anyway, so
you will probably want to leave allocation of net_device structure to
this function too. And it is probably better to have correspondent
ieee80211_register function to prevent confusion (even if the only thing
done in ieee80211_register is calling netdev_register).

Received frames would be marked as having a protocol type of 802.11, and
the 802.11 code would register itself as a protocol handler for this
protocol type. Now netif_rx() could be used within the hardware driver
to pass frames to the kernel 802.11 code

How will you pass data like signal strength or rate to 802.11 stack?

- this has the benefit of
better performance for the hardirq/softirq transition than the current
scheme.

I don't see much benefit in this. Instead of rewriting big part of the
stack (and drivers as well) for questionable performance gain I would
rather see a work on putting the stack to mainline - the only blockers
left are SMP safety and stack<->hostapd netlink protocol. Oh, and better
communication with tools like NetworkManager.

On the transmit side - currently the 802.11 code does much
processing within the hard_start_xmit function on the master device. I
would move all this processing into the 802.11 qdisc - putting it into
the dequeue function.

This makes sense, especially fragmentation is a good candidate (and this
implies nearly the whole processing needs to be moved there as well).
Though most of these problems will vanish when the Ethernet<->802.11
conversion routines are removed and the stack starts working with native
802.11 frames.

Now the hard_start_xmit function would be the real
hardware drivers transmit function.

No need for this.

I also think that moving xmit processing to qdisc doesn't need to be
done now. It can be done without changing drivers, so we can do it after
the stack goes into mainline.

Thanks,

 Jiri

-- 
Jiri Benc
SUSE Labs