On Wed, Jan 18, 2006 at 12:36:09AM +0100, Stefan Rompf wrote: > prism2 usb is even worse - the urb is build of some control structure, the > 802.11 3 address header, a 802.3 header and the 802.11 data part. Some bits > in the control structure decide whether the 802.11 or the 802.3 header is > used to create the frame sent to the air. I actually maintain a prism2 usb driver. It's host interface is truly fscked, and then there are the unfixable hardware bugs... But back to your point -- It's actually true of all prism2 devices. You can use one header or the other, but space for both is part of the fixed packet structure. Meanwhile, I've only seen one wireless chipset that *requires* 802.3 headers, and that is the prism54/prismGT/Indigo/Duette (FullMAC mode). Those adapters (except for the Indigo, which never made it into production anyway) can run in a softmac mode, which uses regular 802.11 headers. It's actually fairly common that hardware devices have the 802.11 header separated from the 802.11 payload slightly, if for no other reason that they need space to add the encryption headers. You can't make any assumptions. > Fortunately, a driver should be able to specify it's additional memory need at > the front of the frame via hard_header_len. Some drivers will need to do some > ugly memmove()s at the packet begin then. This amount also varies with different encryption modes. And don't forget you also need space for an LLC+SNAP header and finally, you need a frame footer for encryption as well. > .. and it gets even worse as soon as we start encrypting packets. I think we > should start using the netdev wiki at http://linux-net.osdl.org/ to collect > information. For this part of the discussion, we need to know what transmit > frame formats different hardware needs. They're all over the map, yes.. there's no guarantee that the frame will be contiguious. It's annoying.. They also vary depending on encrpytion mode. Keep the 802.11 stack generic; split the packet into its logical block. On a per-frame basis, you have: - 802.11 header (variable length) - Encryption header (variable length) - LLC+SNAP header on payload (which we may need to add) - actual payload - Encryption footer (variable length) How's this strawman proposal: wiphy_frame_xmit (struct wiphy_dev *dev, struct sk_buff *skb); skb->data points to the raw payload, with LLC+SNAP header. skb->cb points to a structure that has, among other things: - 802.11 header + length - encryption header + length - encryption footer + length - desired data rate(s), antenna, rts/cts, and other tx params. - hw/sw encryption flag, and the key needed to encrypt. Given that I haven't seen two chipsets that do thigns the same way, there's little point in making the stack generic enough to rearrange these bits in the correct places. That said, we could provide a generic coalesce method for the general swcrypto+payload case, where the hardware would presumably treat it as an opaque payload. Each driver would be responsible for rearranging these chunks as appropriate, ideally using scatter-gather DMA. That's why the chunks are all specified as chunk+len; the driver can blindly copy the chunks without worrying about their contents. Chipsets that require payload padding when using crypto can tell the 802.11 stack of this requirement, and the stack will pass the appropriate pads in via the crypt_header and crypt_footer. I've put this stuff on the wiki, for what it's worth. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur.
Attachment:
pgpVsxc2q8S1D.pgp
Description: PGP signature
- References:
- Re: wireless: recap of current issues (other issues)
- From: Jeff Garzik <[email protected]>
- Re: wireless: recap of current issues (other issues)
- From: Stuffed Crust <[email protected]>
- Re: wireless: recap of current issues (other issues / fake ethernet)
- From: Stefan Rompf <[email protected]>
- Re: wireless: recap of current issues (other issues)
- Prev by Date: Re: Why is wmb() a no-op on x86_64?
- Next by Date: [PATCH 1/8] Notifier chain update
- Previous by thread: Re: wireless: recap of current issues (other issues / fake ethernet)
- Next by thread: wireless: recap of current issues (actions)
- Index(es):
 |