Has it been considered to simply treat all wireless hardware as
SoftMAC and to just ignore the FullMAC capabilities?
Doing this would effectively turn all wireless hardware on Linux into
commodities stopping this chaos of all the different implementations.
Network speeds on wireless are not very high, things may even be
faster if done on the main CPU.
Wired networking went through this exact process in the 80's. There
were cards with complete TCP systems running on embedded processors.
Ultimately this shook out to the dumb hardware we have today. This
happened for two reasons, the main CPU was cheaper/faster and there
were fewer interoperability problems when only a couple of stacks were
being used instead of dozens.
Dscape looks to have already started down this path with
implementations for five vendors. Is the plan to do this for all
vendors, including Intel and Atheros?
My specific need is that I am working on an embedded design that
really needs 802.11s, but 11s isn't available yet. I don't want to end
up locked into a hardware vendor's FullMAC implementation with much
more expensive hardware. Currently hardware can run 11s if there is a
host implementation in software.
Meanwhile I am trying to hack something together using OLSR. Is there
a better way to get mesh working?
--
Jon Smirl
[email protected]
On 2/4/07, Pavel Roskin <[email protected]> wrote:
> In fact, Atheros chips are not that intelligent to be treated as FullMAC, but
> going to d80211 removes many chip specific features.
What types of features are removed? For example Atheros turbo mode can
be treated like another PHY layer implementation.
If it is just off-loading the implementation of standard behavior then
we may actually be better off ignoring this capability and
implementing the standard behavior in the host.
It's not even clear to me that doing encryption is a wireless
co-processor is a win. It is almost certain that the host can perform
the same algorithms many times faster that an embedded wireless
processor. Moving encryption onto the host reduces the latency of the
connection.
--
Jon Smirl
[email protected]
On Sunday 04 February 2007 20:44, Jon Smirl wrote:
> On 2/4/07, Michael Buesch <[email protected]> wrote:
> > On Sunday 04 February 2007 19:31, Jon Smirl wrote:
> > > On 2/4/07, Pavel Roskin <[email protected]> wrote:
> > > > In fact, Atheros chips are not that intelligent to be treated as FullMAC, but
> > > > going to d80211 removes many chip specific features.
> > >
> > > What types of features are removed? For example Atheros turbo mode can
> > > be treated like another PHY layer implementation.
> > >
> > > If it is just off-loading the implementation of standard behavior then
> > > we may actually be better off ignoring this capability and
> > > implementing the standard behavior in the host.
> > >
> > > It's not even clear to me that doing encryption is a wireless
> > > co-processor is a win. It is almost certain that the host can perform
> > > the same algorithms many times faster that an embedded wireless
> > > processor. Moving encryption onto the host reduces the latency of the
> > > connection.
> >
> > If creating and uploading the keys to the device is less work than
> > doing crypto in software, then it is clearly a win.
> > And that _is_ the case for bcm43xx (at least. I don't know about other
> > devices' hwcrypto capabilities).
> > Doing less on the CPU and more in hw is always a win. I'm not sure
> > how you can say that you're not sure it is. ;)
>
> Don't get too focused on the crypto question, this is more of a
> philosophical question. What happened in the wired world was the
> creation of total software implementations. These software
> implementations had hooks for off-load, but the implementations
> implemented all of the stack in software. To get a new piece of
> hardware running all you had to do was provide basic send/receive
> functions.
>
> The model where all the hardware had to do was send/receive plus some
> bookkeeping led to an explosion in the amount of networking hardware
> supported under Windows (I was in the MS networking group when NDIS
> was built). Previous to NDIS it had been a major process interfacing
> the coprocessor based network cards into the MS networking stack.
> Every card needed it's own set of hooks and the vendors kept changing
> the features supported (reminds you of the current situation with
> FullMAC?).
>
> In the Windows case the software stack had another side effect, if you
> ran the hardware in software mode it always interoperated. That was
> because both sides were running the same software. Switching to
> software only mode exposed thousands of bugs in hardware and software
> implementations by the vendors.
>
> This same model also existing the the graphics world. Mesa implements
> the entire OpenGL stack in software. Hardware drivers then overlay
> functions in Mesa with accelerated implementations.
>
> Obviously you would quickly provide drivers that accelerate the low
> hanging fruit like encryption, but there is always the software
> fallback available. Also note that after the transition to dumb
> Ethernet hardware around 1990, it was 2002 or so before TCP checksum
> offload became a win, and it is still controversial if it really is a
> win.
>
> I was looking at the problem from the context of 11s. If hardware uses
> a minimal software MAC and everything else is done in host software,
> then a software 11s implementation would enable all the hardware in
> this model to work immediately. If the FullMAC model is followed
> instead it may be years, if ever, before a majority of Linus wireless
> hardware becomes enabled for 11s.
I don't really see your point.
We can't change hardware. We have to implement the software around existing
hardware. And that's currently softmac _and_ fullmac devices.
So we have to create hooks and so on in our software to support
the fullmac devices.
--
Greetings Michael.
On Sunday 04 February 2007 20:41, Jouni Malinen wrote:
> On Sun, Feb 04, 2007 at 08:07:29PM +0100, Michael Buesch wrote:
>
> > If creating and uploading the keys to the device is less work than
> > doing crypto in software, then it is clearly a win.
>
> Not necessarily..
>
> > And that _is_ the case for bcm43xx (at least. I don't know about other
> > devices' hwcrypto capabilities).
> > Doing less on the CPU and more in hw is always a win. I'm not sure
> > how you can say that you're not sure it is. ;)
>
> As an example, some of the earlier Prism2 designs supported WEP in
> hardware/firmware. Yes, it would free up some host CPU, but the maximum
> throughput dropped from ca. 6 Mbps to 4 Mbps (and much lower in some
> cases).. WEP is quite fast operation, so using the host CPU to double
> throughput sounds like a good trade in many cases.
Yeah, ok. I was more thinking about sane hardware that's actually
capable of doing hwcrypto. :)
Sure, you're right. This prism2 card has to be treated as
swcrypto device, as it's cleary not capable of handling the load.
--
Greetings Michael.
On Sun, Feb 04, 2007 at 01:31:27PM -0500, Jon Smirl wrote:
> It's not even clear to me that doing encryption is a wireless
> co-processor is a win. It is almost certain that the host can perform
> the same algorithms many times faster that an embedded wireless
> processor. Moving encryption onto the host reduces the latency of the
> connection.
Well, maybe in some use cases like a modern desktop/laptop CPU with
plenty of CPU power, but hardware acceleration for encryption is a huge
win on most embedded systems (e.g., APs). And like I mentioned, some
FullMAC designs do not even allow the encryption to be moved to the
host..
--
Jouni Malinen PGP id EFC895FA
Quoting Jon Smirl <[email protected]>:
> Has it been considered to simply treat all wireless hardware as
> SoftMAC and to just ignore the FullMAC capabilities?
[skip]
> Dscape looks to have already started down this path with
> implementations for five vendors. Is the plan to do this for all
> vendors, including Intel and Atheros?
It is the plan for Atheros. See Dadwifi.
In fact, Atheros chips are not that intelligent to be treated as FullMAC, but
going to d80211 removes many chip specific features.
--
Regards,
Pavel Roskin
On Sunday 04 February 2007 19:31, Jon Smirl wrote:
> On 2/4/07, Pavel Roskin <[email protected]> wrote:
> > In fact, Atheros chips are not that intelligent to be treated as FullMAC, but
> > going to d80211 removes many chip specific features.
>
> What types of features are removed? For example Atheros turbo mode can
> be treated like another PHY layer implementation.
>
> If it is just off-loading the implementation of standard behavior then
> we may actually be better off ignoring this capability and
> implementing the standard behavior in the host.
>
> It's not even clear to me that doing encryption is a wireless
> co-processor is a win. It is almost certain that the host can perform
> the same algorithms many times faster that an embedded wireless
> processor. Moving encryption onto the host reduces the latency of the
> connection.
If creating and uploading the keys to the device is less work than
doing crypto in software, then it is clearly a win.
And that _is_ the case for bcm43xx (at least. I don't know about other
devices' hwcrypto capabilities).
Doing less on the CPU and more in hw is always a win. I'm not sure
how you can say that you're not sure it is. ;)
Additionally, doing crypto in the RX path (tasklet context) is
not really optimal, from a latency point of view.
But you can test it yourself. Enable/disable hwcrypto and watch how
CPU load in "top" reacts.
I did a quick test on my powerbook and software interrupt load
decreases from about 30% to about 10% when switching from swcrypto
to hwcrypto. I'd call that a significant win. And this 20% decrease
is just the RX path. TX is done in process context (I think).
--
Greetings Michael.
On 2/5/07, Luis R. Rodriguez <[email protected]> wrote:
> just because it makes our lives easier. MS may have done what they did
> to help with their development efforts but it doesn't mean it was
> necessarily good for technology. We want to work with vendors to
> support their devices regardless of how stupid their design is --
> ultimately our job is to support hardware for our users and not take
> on political quests to dictate the path of technology.
I wouldn't say MS did this for political reasons, I believe it was
more for technical reasons based on the simple observation that the
host CPU was 5-10 times the speed of the coprocessors. The dumb
Ethernet card design was also lower cost which expanded the market.
3COM actually came up with NDIS and then MS adopted it.
For the 'smart' card vendors they then had to implement the stack all
the way up to the NETBIOS layer without help from MS. They weren't
shut out, but they got no support either. The burden of software
implementation, plus the fact that the cards were 10x more expensive
and slower, led to their ultimate failure.
Looking back on this NDIS really helped the LAN industry by
commoditizing the hardware. The market hugely expanded since the
hardware was dirt cheap and very easy to use.
--
Jon Smirl
[email protected]
On Sun, Feb 04, 2007 at 12:22:15PM -0500, Jon Smirl wrote:
> Has it been considered to simply treat all wireless hardware as
> SoftMAC and to just ignore the FullMAC capabilities?
There are number of FullMAC designs that do not allow management
functionality to be moved to the host, so this consideration is not
going to go very far unless one were to drop support for all the FullMAC
designs that do not allow this..
> Dscape looks to have already started down this path with
> implementations for five vendors. Is the plan to do this for all
> vendors, including Intel and Atheros?
Atheros (well, assuming you don't mean the USB design here) does not
even use firmware, so it is not FullMAC card in any way.. There is
already work on supporting Intel ipw3945 with d80211. Other Intel
designs (ipw2100, ipw2200, ipw2915) are currently using more FullMAC
type design, but that depends on the firmware implementation.. I don't
know what the hardware would be capable of doing, but in theory, it
might be possible (for the vendor) to produce a firmware version that
could work soft MAC designs.
> My specific need is that I am working on an embedded design that
> really needs 802.11s, but 11s isn't available yet. I don't want to end
> up locked into a hardware vendor's FullMAC implementation with much
> more expensive hardware. Currently hardware can run 11s if there is a
> host implementation in software.
I hope you realize that 802.11s is in very early steps (the first draft
failed to get the needed approval rate in IEEE 802.11 working group) and
is subject to change.. Whether hardware can run 802.11s (the current
draft or whatever may end up in the end) is quite open question from my
view point.. 802.11 requires MAC changes and I'm sure there are hardware
designs that do not work with the current 802.11s draft no matter what
the host CPU is doing in the driver/802.11 stack.
--
Jouni Malinen PGP id EFC895FA
On 2/4/07, Jon Smirl <[email protected]> wrote:
> On 2/4/07, Michael Buesch <[email protected]> wrote:
> > I don't really see your point.
> > We can't change hardware. We have to implement the software around existing
> > hardware. And that's currently softmac _and_ fullmac devices.
> > So we have to create hooks and so on in our software to support
> > the fullmac devices.
>
> What happened at Microsoft in the Ethernet case is that MS stopped
> supporting FullMAC and told the vendors to come up with SoftMAC type
> drivers. For some cards the vendors wrote the software drivers and for
> others MS did. Not all of the vendors agreed to this and most of those
> companies are no longer around.
>
> The point is that Linux could simply design out the FullMAC hardware
> that didn't also make a basic SoftMAC interface available. The primary
> wireless implementation for Linux would be a fully software based
> implementation that all hardware would be required to minimally work
> with. The main kernel wireless developers would then focus their
> attention on the software stack implementation instead of dealing with
> all of the various firmware messes and uncooperative vendors.
>
> This model is pretty close to happening with the Dscape stack. Once
> Dscape goes in, notice could be given that the other implementations
> will be removed in a year.
>
> Of course Linux doesn't have the same kind of power over the vendors
> like MS does. But it doesn't mean that this model wouldn't work for
> Linux. The concept of a single top to bottom software based reference
> implementation with hooks for hardware acceleration is a sound design.
Current wireless cognitive radio research is ambitiously trying to to
come up with a framework where certain functions can exist in either
hardware and/or software; but it is very important to note that,
mainly due to timing differences, it is by no means trivial to come up
with proper encapsulation of hardware implemented blocks so that they
are easily blended in a full software framework. Additionally, since
FullMAC solutions may currently provide the best solutions for certain
situations (power requirements for embedded devices being the most
common I've heard) and since we do want to take part in projects which
make use of these solutions (OLPC being one) we cannot, and I think
should not, try to mandate vendors to adopt SoftMAC solutions only
just because it makes our lives easier. MS may have done what they did
to help with their development efforts but it doesn't mean it was
necessarily good for technology. We want to work with vendors to
support their devices regardless of how stupid their design is --
ultimately our job is to support hardware for our users and not take
on political quests to dictate the path of technology.
Luis
On 2/4/07, Michael Buesch <[email protected]> wrote:
> I don't really see your point.
> We can't change hardware. We have to implement the software around existing
> hardware. And that's currently softmac _and_ fullmac devices.
> So we have to create hooks and so on in our software to support
> the fullmac devices.
What happened at Microsoft in the Ethernet case is that MS stopped
supporting FullMAC and told the vendors to come up with SoftMAC type
drivers. For some cards the vendors wrote the software drivers and for
others MS did. Not all of the vendors agreed to this and most of those
companies are no longer around.
The point is that Linux could simply design out the FullMAC hardware
that didn't also make a basic SoftMAC interface available. The primary
wireless implementation for Linux would be a fully software based
implementation that all hardware would be required to minimally work
with. The main kernel wireless developers would then focus their
attention on the software stack implementation instead of dealing with
all of the various firmware messes and uncooperative vendors.
This model is pretty close to happening with the Dscape stack. Once
Dscape goes in, notice could be given that the other implementations
will be removed in a year.
Of course Linux doesn't have the same kind of power over the vendors
like MS does. But it doesn't mean that this model wouldn't work for
Linux. The concept of a single top to bottom software based reference
implementation with hooks for hardware acceleration is a sound design.
--
Jon Smirl
[email protected]
On 2/4/07, Michael Buesch <[email protected]> wrote:
> On Sunday 04 February 2007 19:31, Jon Smirl wrote:
> > On 2/4/07, Pavel Roskin <[email protected]> wrote:
> > > In fact, Atheros chips are not that intelligent to be treated as FullMAC, but
> > > going to d80211 removes many chip specific features.
> >
> > What types of features are removed? For example Atheros turbo mode can
> > be treated like another PHY layer implementation.
> >
> > If it is just off-loading the implementation of standard behavior then
> > we may actually be better off ignoring this capability and
> > implementing the standard behavior in the host.
> >
> > It's not even clear to me that doing encryption is a wireless
> > co-processor is a win. It is almost certain that the host can perform
> > the same algorithms many times faster that an embedded wireless
> > processor. Moving encryption onto the host reduces the latency of the
> > connection.
>
> If creating and uploading the keys to the device is less work than
> doing crypto in software, then it is clearly a win.
> And that _is_ the case for bcm43xx (at least. I don't know about other
> devices' hwcrypto capabilities).
> Doing less on the CPU and more in hw is always a win. I'm not sure
> how you can say that you're not sure it is. ;)
Don't get too focused on the crypto question, this is more of a
philosophical question. What happened in the wired world was the
creation of total software implementations. These software
implementations had hooks for off-load, but the implementations
implemented all of the stack in software. To get a new piece of
hardware running all you had to do was provide basic send/receive
functions.
The model where all the hardware had to do was send/receive plus some
bookkeeping led to an explosion in the amount of networking hardware
supported under Windows (I was in the MS networking group when NDIS
was built). Previous to NDIS it had been a major process interfacing
the coprocessor based network cards into the MS networking stack.
Every card needed it's own set of hooks and the vendors kept changing
the features supported (reminds you of the current situation with
FullMAC?).
In the Windows case the software stack had another side effect, if you
ran the hardware in software mode it always interoperated. That was
because both sides were running the same software. Switching to
software only mode exposed thousands of bugs in hardware and software
implementations by the vendors.
This same model also existing the the graphics world. Mesa implements
the entire OpenGL stack in software. Hardware drivers then overlay
functions in Mesa with accelerated implementations.
Obviously you would quickly provide drivers that accelerate the low
hanging fruit like encryption, but there is always the software
fallback available. Also note that after the transition to dumb
Ethernet hardware around 1990, it was 2002 or so before TCP checksum
offload became a win, and it is still controversial if it really is a
win.
I was looking at the problem from the context of 11s. If hardware uses
a minimal software MAC and everything else is done in host software,
then a software 11s implementation would enable all the hardware in
this model to work immediately. If the FullMAC model is followed
instead it may be years, if ever, before a majority of Linus wireless
hardware becomes enabled for 11s.
> Additionally, doing crypto in the RX path (tasklet context) is
> not really optimal, from a latency point of view.
>
> But you can test it yourself. Enable/disable hwcrypto and watch how
> CPU load in "top" reacts.
>
> I did a quick test on my powerbook and software interrupt load
> decreases from about 30% to about 10% when switching from swcrypto
> to hwcrypto. I'd call that a significant win. And this 20% decrease
> is just the RX path. TX is done in process context (I think).
>
> --
> Greetings Michael.
>
--
Jon Smirl
[email protected]
On Sun, Feb 04, 2007 at 08:07:29PM +0100, Michael Buesch wrote:
> If creating and uploading the keys to the device is less work than
> doing crypto in software, then it is clearly a win.
Not necessarily..
> And that _is_ the case for bcm43xx (at least. I don't know about other
> devices' hwcrypto capabilities).
> Doing less on the CPU and more in hw is always a win. I'm not sure
> how you can say that you're not sure it is. ;)
As an example, some of the earlier Prism2 designs supported WEP in
hardware/firmware. Yes, it would free up some host CPU, but the maximum
throughput dropped from ca. 6 Mbps to 4 Mbps (and much lower in some
cases).. WEP is quite fast operation, so using the host CPU to double
throughput sounds like a good trade in many cases.
--
Jouni Malinen PGP id EFC895FA
On Sun, Feb 04, 2007 at 01:24:03PM -0500, Jon Smirl wrote:
> What I've read is that there are no changes at the PHY layers for 11s.
> If that is the case then any existing hardware should be able to run
> 11s if the interface allows properly formatted packets to be
> transmitted and received. Of course I don't know exactly what is in
> the 11s draft since it is secret.
Hardware may be able to take care of most needed functionality, but
whether firmware is going to allow this is completely different
question.. Amongst other things, IEEE 802.11s/D1.0 is adding new fields
to the frame headers and that is likely to get into problems with number
of firmware implementations.
> A related issue is merging the Marvell support for the OLPC. Marvell
> is doing a FullMAC 11s implementation which requires a coprocessor in
> the wireless hardware. Merging a firmware 11s implementation before a
> software 11s implementation exists will likely cause problems since
> interfaces won't get designed correctly.
I would not call that 11s. It may be a snapshot of a proposal for
802.11s, but IEEE 802.11s is far from being complete, so better call
this Marvell implementation something else.
> I'm concerned that's the vendor's goal is to require a new round of
> hardware purchases to support 11s when it doesn't appear to be
> necessary. OLPC needs the firmware implementation for power saving
> reasons, not to implement the protocol.
Vendors are usually more interested in selling new hardware than adding
support for new functionality in old firmware (no money coming in)..
--
Jouni Malinen PGP id EFC895FA
On 2/4/07, Jouni Malinen <[email protected]> wrote:
> I hope you realize that 802.11s is in very early steps (the first draft
> failed to get the needed approval rate in IEEE 802.11 working group) and
> is subject to change.. Whether hardware can run 802.11s (the current
> draft or whatever may end up in the end) is quite open question from my
> view point.. 802.11 requires MAC changes and I'm sure there are hardware
> designs that do not work with the current 802.11s draft no matter what
> the host CPU is doing in the driver/802.11 stack.
What I've read is that there are no changes at the PHY layers for 11s.
If that is the case then any existing hardware should be able to run
11s if the interface allows properly formatted packets to be
transmitted and received. Of course I don't know exactly what is in
the 11s draft since it is secret.
A related issue is merging the Marvell support for the OLPC. Marvell
is doing a FullMAC 11s implementation which requires a coprocessor in
the wireless hardware. Merging a firmware 11s implementation before a
software 11s implementation exists will likely cause problems since
interfaces won't get designed correctly.
I'm concerned that's the vendor's goal is to require a new round of
hardware purchases to support 11s when it doesn't appear to be
necessary. OLPC needs the firmware implementation for power saving
reasons, not to implement the protocol.
--
Jon Smirl
[email protected]