Search Linux Wireless

Re: SoftMAC vs FullMAC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sunday 04 February 2007 20:44, Jon Smirl wrote:
> On 2/4/07, Michael Buesch <mb@xxxxxxxxx> wrote:
> > On Sunday 04 February 2007 19:31, Jon Smirl wrote:
> > > On 2/4/07, Pavel Roskin <proski@xxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux