Linux wireless networking development ()

Jon Smirl | 4 Feb 18:22

Picon

SoftMAC vs FullMAC

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

(Continue reading)

Jouni Malinen | 4 Feb 19:07

Picon

Picon

Re: SoftMAC vs FullMAC

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

(Continue reading)

Jon Smirl | 4 Feb 19:24

Picon

Re: SoftMAC vs FullMAC

On 2/4/07, Jouni Malinen <jkmaline@...> 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
jonsmirl@...
-

(Continue reading)

Jouni Malinen | 4 Feb 19:47

Picon

Picon

Re: SoftMAC vs FullMAC

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

(Continue reading)

Pavel Roskin | 4 Feb 18:30

Picon

Re: SoftMAC vs FullMAC

Quoting Jon Smirl <jonsmirl@...>:

> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jon Smirl | 4 Feb 19:31

Picon

Re: SoftMAC vs FullMAC

On 2/4/07, Pavel Roskin <proski@...> 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
jonsmirl@...
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michael Buesch | 4 Feb 20:07

Picon

Re: SoftMAC vs FullMAC

On Sunday 04 February 2007 19:31, Jon Smirl wrote:
> On 2/4/07, Pavel Roskin <proski@...> 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.

(Continue reading)

Jon Smirl | 4 Feb 20:44

Picon

Re: SoftMAC vs FullMAC

On 2/4/07, Michael Buesch <mb@...> wrote:
> On Sunday 04 February 2007 19:31, Jon Smirl wrote:
> > On 2/4/07, Pavel Roskin <proski@...> 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

(Continue reading)

Michael Buesch | 4 Feb 21:11

Picon

Re: SoftMAC vs FullMAC

On Sunday 04 February 2007 20:44, Jon Smirl wrote:
> On 2/4/07, Michael Buesch <mb@...> wrote:
> > On Sunday 04 February 2007 19:31, Jon Smirl wrote:
> > > On 2/4/07, Pavel Roskin <proski@...> 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

(Continue reading)

Jon Smirl | 4 Feb 21:46

Picon

Re: SoftMAC vs FullMAC

On 2/4/07, Michael Buesch <mb@...> 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.

(Continue reading)

Luis R. Rodriguez | 5 Feb 09:28

Picon

Re: SoftMAC vs FullMAC

On 2/4/07, Jon Smirl <jonsmirl@...> wrote:
> On 2/4/07, Michael Buesch <mb@...> 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.

(Continue reading)

Jon Smirl | 5 Feb 15:56

Picon

Re: SoftMAC vs FullMAC

On 2/5/07, Luis R. Rodriguez <mcgrof@...> 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
jonsmirl@...
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...

(Continue reading)

Jouni Malinen | 4 Feb 20:41

Picon

Picon

Re: SoftMAC vs FullMAC

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
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Michael Buesch | 4 Feb 21:05

Picon

Re: SoftMAC vs FullMAC

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Jouni Malinen | 4 Feb 19:43

Picon

Picon

Re: SoftMAC vs FullMAC

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
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Return

Return to gmane.linux.kernel.wireless.general.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane