On Sun, May 31, 2015 at 2:01 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Sun, 2015-05-31 at 04:58 +0530, Chaitanya T K wrote: >> cfg80211 reuses the skb before asking for a fresh on from genl framework, >> this works efficiently for smaller messages but NLM_F_DUMP is normally >> used to transport larger data normally > PAGE_SIZE, so if the message >> occupies more than GOODSIZE its better to ask for a new, saves couple >> of hanshakes with the driver. >> >> This improves the time to get the DUMP response across to user space. > > This doesn't make any sense. If the driver is slow to actually create > the data, it should implement this logic, but realistically the driver > should just check if there's enough space and only try to create data to > put into the skb if it's sufficient? > > It sounds to me like you're actually interacting with the hardware at > this point (otherwise it wouldn't be slow!) which pretty much seems > wrong anyway. In our case the data size is 411KB, and each message carries around 3072 bytes, so total messages would be 138. The first message we get, we retrieve the data, and for subsequent messages we just fill the skb, we are not interacting with the hardware. Without this patch, heres the sequence: genl->cfg80211->retrieve the dump from HW, skb_put: 3072 cfg80211->skb_put, fail genl->cfg80211->skb_put: 3072. With this patch: genl->cfg80211->retrive the dump from HW, skb_put: 3072 genl->cfg80211->skb_put: 3072. -- 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