headers
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
Permalink | Reply |
headers
Jon Smirl | 4 Feb 19:31
Picon
Gravatar

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
Permalink | Reply |
headers
Michael Buesch | 4 Feb 20:07
Picon
Favicon

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)

Permalink | Reply |
headers
Jon Smirl | 4 Feb 20:44
Picon
Gravatar

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)

Permalink | Reply |
headers
Michael Buesch | 4 Feb 21:11
Picon
Favicon

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)

Permalink | Reply |
headers
Jon Smirl | 4 Feb 21:46
Picon
Gravatar

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)

Permalink | Reply |
headers
Luis R. Rodriguez | 5 Feb 09:28
Picon
Gravatar

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)

Permalink | Reply |
headers
Jon Smirl | 5 Feb 15:56
Picon
Gravatar

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)

Permalink | Reply |
headers
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
Permalink | Reply |
headers
Michael Buesch | 4 Feb 21:05
Picon
Favicon

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)

Permalink | Reply |
headers
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
Permalink | Reply |

Gmane