[rt2x00-users] [RFC PATCH repeat] rt2x00: FIF_PSPOLL filter flag support

Igor Perminov igor.perminov at inbox.ru
Mon Aug 3 20:13:36 UTC 2009


Hi,

> I don't see the need for DRIVER_HAS_MULTIPLE_CONTROL_FILTER, all drivers support
> the CONTROL filter, only a few others support more fine-grained levels for PSPOLL.

The purpose of DRIVER_HAS_MULTIPLE_CONTROL_FILTER is a performance
optimization: not to receive all control frames whenever it's possible.

> So isn't having a DRIVER_SUPPORT_PSPOLL_FILTER flag sufficient?
> That way if the driver sets the flag we can handle the FIF_ flags individually,
> otherwise havign FIF_CONTROL implies FIF_PSPOLL and FIF_PSPOLL implies FIF_CONTROL.

In case FIF_PSPOLL implies FIF_CONTROL, the driver will receive from the
hardware and pass to mac80211 all control frames, when PS Poll ones are
required only. It leads to performance overhead: ACK frames are a
sufficient part of traffic.

> You also said that rt2500usb and rt73usb work with this patch, seeing that you
> made no changes to rt2500usb and the PSPOLL filter support works the same in both
> devices the usage of DRIVER_HAS_MULTIPLE_CONTROL_FILTER suggests it isn't
> needed. ;)
> 
> That will make your patch a bit easier since you won't need to change anything
> to rt61pci and rt73usb. ;)

rt2400pci, rt2500pci and rt2500usb has one common filter for all control
frames, so there is no subject for any optimization for them.

rt61pci and rt73usb can filter out ACK and CTS frames independently of
other control frames (am I right? I see usage of TXRX_CSR0_DROP_ACK_CTS
in rt61pci_config_filter and rt73usb_config_filter...).
So, when PS Poll frames are required only, we can filter out ACK and CTS
frames at the hardware level and reduce the amount of frames being
passed to mac80211 for these drivers.

If you object to DRIVER_HAS_MULTIPLE_CONTROL_FILTER, there can be a
solution without it, but I think it isn't more optimal:
* There is DRIVER_HAS_PSPOLL_FILTER capability only.
* If DRIVER_HAS_PSPOLL_FILTER isn't set for the driver, then FIF_CONTROL
implies FIF_PSPOLL (but *not* vice versa).
* RXCSR0_DROP_CONTROL (rt2400pci/rt2500pci), TXRX_CSR2_DROP_CONTROL
(rt2500usb), TXRX_CSR0_DROP_CONTROL (rt61pci/rt73usb) are controlled by
both FIF_CONTROL and FIF_PSPOLL in xxx_config_filter, i.e.:
    rt2x00_set_field32(&reg, XXX_DROP_CONTROL,
        !(filter_flags & (FIF_CONTROL | FIF_PSPOLL)));

That solution has two disadvantages:
1. We have to modify rt2400pci/rt2500pci/rt2500usb code in addition to
rt61pci/rt73usb.
2. rt2400pci/rt2500pci/rt2500usb will disappoint mac80211: in case
FIF_PSPOLL without FIF_CONTROL will be passed by mac80211 to driver's
configure_filter, the driver won't return FIF_CONTROL in *total_flags,
but will pass all control frames to mac80211.

What do you think of it?

Igor





More information about the users mailing list