Hi, > > Can you explain what for? :-) > > We want to set NoAck for special traffic classes like video or voice where > "old" packets are not useful, but keep it for background and best effort traffic. > This can be applied on devices supporting both traffic classes (e.g. > laptops, smartphones with VoIP software) as well as for backhaul links. Ok. > > I'm not sure this API is really the best way to handle it either, like I > > just said it might be nicer per connection or so to get reset properly. > > > > I'm not sure what you mean by "per connection" - do you mean per AP/Sta > connection? We need definitely need it per queue as explained above. No, I mean ... it could be a parameter to connect() or associate(), which would get a bitmap of ACs to use no-ack policy for, instead of an explicit new configuration. > > > I have tested this feature on ath9k as well as ath5k devices. There is > > > an iw patch as well to make use of this feature. > > > > Since you're adding 'real API' (unlike the debugfs file which you should > > probably remove now!) you also should think about drivers like mwifiex > > that don't support this and don't use mac80211. > > mwifiex neither supports set_txq_params nor the new function, nl80211 should > just return "-EOPNOTSUPP". A short grep revealed that no driver in wireless-testing > implements set_txq_params so far, so at least for the drivers within the kernel > this should be safe. I forgot to explicitly check for rdev->ops->set_txq_noack > and will add this check in v2 ... Good point -- but if you'd change to make it a parameter for connect and associate (I think that is better since it will clean up by itself properly when disconnecting) then you would need some flag indicating that the driver/device supports this (with mac80211 obviously always supporting it). johannes -- 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
