Message ID | 1249656135.7194.6.camel@johannes.local (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
Hi, > If we have a lot of frames to transmit at once, for > instance with fragmentation, it can be an optimisation > to only tell the DMA engine about them on the last > fragment/frame to avoid banging the IO too much. This > patch allows implementation such an optimisation by > telling the driver when more frames can be expected. Wouldn't this be the same as the if (ieee80211_has_morefrags()) .. kick queue ... Other then that this flag is very nice, I already had some similar sort of mechanism build into rt2x00 based on RTS/CTS and ieee80211_has_morefrags() > Currently, this is used by mac80211 only on fragmented > frames, but could also be used in the future on other > frames when the queue was full and there are multiple > frames pending. > > Note that drivers need to be careful when using this > flag, they need to kick their DMA engines not just > when this flag is clear, but also when the queue gets > full so that progress can be made. What would a good value be for the threshold? rt2x00 currently uses 10% of the queue, which means that 2 or 3 entries are kept available at all times. Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2009-08-07 at 18:55 +0200, Ivo van Doorn wrote: > > If we have a lot of frames to transmit at once, for > > instance with fragmentation, it can be an optimisation > > to only tell the DMA engine about them on the last > > fragment/frame to avoid banging the IO too much. This > > patch allows implementation such an optimisation by > > telling the driver when more frames can be expected. > > Wouldn't this be the same as the > if (ieee80211_has_morefrags()) > .. kick queue ... Initially, yes, but I think we should eventually use it for sending out multiple frames after restarting queues etc. For instance after scanning, we could send out a bunch of frames at once. > > Currently, this is used by mac80211 only on fragmented > > frames, but could also be used in the future on other > > frames when the queue was full and there are multiple > > frames pending. > > > > Note that drivers need to be careful when using this > > flag, they need to kick their DMA engines not just > > when this flag is clear, but also when the queue gets > > full so that progress can be made. > > What would a good value be for the threshold? > rt2x00 currently uses 10% of the queue, which means that > 2 or 3 entries are kept available at all times. Well, for fragmentation I think the maximum number of fragments is 9. johannes
On Friday 07 August 2009, Johannes Berg wrote: > On Fri, 2009-08-07 at 18:55 +0200, Ivo van Doorn wrote: > > > > If we have a lot of frames to transmit at once, for > > > instance with fragmentation, it can be an optimisation > > > to only tell the DMA engine about them on the last > > > fragment/frame to avoid banging the IO too much. This > > > patch allows implementation such an optimisation by > > > telling the driver when more frames can be expected. > > > > Wouldn't this be the same as the > > if (ieee80211_has_morefrags()) > > .. kick queue ... > > Initially, yes, but I think we should eventually use it for sending out > multiple frames after restarting queues etc. For instance after > scanning, we could send out a bunch of frames at once. This would work for PCI devices, but USB devices can spoil the fun (as usual) because those devices use the queue in the hardware and you can't control the actual "kick". > > > Currently, this is used by mac80211 only on fragmented > > > frames, but could also be used in the future on other > > > frames when the queue was full and there are multiple > > > frames pending. > > > > > > Note that drivers need to be careful when using this > > > flag, they need to kick their DMA engines not just > > > when this flag is clear, but also when the queue gets > > > full so that progress can be made. > > > > What would a good value be for the threshold? > > rt2x00 currently uses 10% of the queue, which means that > > 2 or 3 entries are kept available at all times. > > Well, for fragmentation I think the maximum number of fragments is 9. Ok, I'll look into increasing the queue size and theshold to something closer to 9. :) Ivo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, 2009-08-07 at 20:21 +0200, Ivo van Doorn wrote: > > Initially, yes, but I think we should eventually use it for sending out > > multiple frames after restarting queues etc. For instance after > > scanning, we could send out a bunch of frames at once. > > This would work for PCI devices, but USB devices can spoil the > fun (as usual) because those devices use the queue in the hardware > and you can't control the actual "kick". Sure, but it's meant as an optimisation anyway. johannes
--- wireless-testing.orig/include/net/mac80211.h 2009-08-07 16:36:27.000000000 +0200 +++ wireless-testing/include/net/mac80211.h 2009-08-07 16:38:37.000000000 +0200 @@ -268,6 +268,10 @@ struct ieee80211_bss_conf { * @IEEE80211_TX_CTL_PSPOLL_RESPONSE: (internal?) * This frame is a response to a PS-poll frame and should be sent * although the station is in powersave mode. + * @IEEE80211_TX_CTL_MORE_FRAMES: More frames will be passed to the + * transmit function after the current frame, this can be used + * by drivers to kick the DMA queue only if unset or when the + * queue gets full. */ enum mac80211_tx_control_flags { IEEE80211_TX_CTL_REQ_TX_STATUS = BIT(0), @@ -288,6 +292,7 @@ enum mac80211_tx_control_flags { IEEE80211_TX_INTFL_RETRIED = BIT(15), IEEE80211_TX_INTFL_DONT_ENCRYPT = BIT(16), IEEE80211_TX_CTL_PSPOLL_RESPONSE = BIT(17), + IEEE80211_TX_CTL_MORE_FRAMES = BIT(18), }; /** --- wireless-testing.orig/net/mac80211/tx.c 2009-08-07 16:38:44.000000000 +0200 +++ wireless-testing/net/mac80211/tx.c 2009-08-07 16:38:51.000000000 +0200 @@ -1154,6 +1154,9 @@ static int __ieee80211_tx(struct ieee802 next = skb->next; len = skb->len; + if (next) + info->flags |= IEEE80211_TX_CTL_MORE_FRAMES; + sdata = vif_to_sdata(info->control.vif); switch (sdata->vif.type) {
If we have a lot of frames to transmit at once, for instance with fragmentation, it can be an optimisation to only tell the DMA engine about them on the last fragment/frame to avoid banging the IO too much. This patch allows implementation such an optimisation by telling the driver when more frames can be expected. Currently, this is used by mac80211 only on fragmented frames, but could also be used in the future on other frames when the queue was full and there are multiple frames pending. Note that drivers need to be careful when using this flag, they need to kick their DMA engines not just when this flag is clear, but also when the queue gets full so that progress can be made. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> --- include/net/mac80211.h | 5 +++++ net/mac80211/tx.c | 3 +++ 2 files changed, 8 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html