On 11/17/10 17:41, Helmut Schaa wrote: > Am Mittwoch 17 November 2010 schrieb Gertjan van Wingerde: >> On Wed, Nov 17, 2010 at 4:07 PM, John W. Linville >> wrote: >>> On Wed, Nov 17, 2010 at 11:48:04AM +0100, Helmut Schaa wrote: >>> >>>> John, should I send a follow-up (with a nice description why it this is needed) >>>> or are you simply reverting this one? >>> >>> Is there no chance for a fix in short order? > > I don't have a clever idea on how to fix that without reverting this commit. > IMO this patch is just not correct as it passes the skb back to mac80211 with > reduced headroom (due to the header & payload alignment) which causes trouble > when mac80211 requeues the frame. Of course just requesting 4 additional bytes > headroom would "fix" the symptoms but sounds like a hack to me. > >> I may have an idea on how we can fix this, without incurring the >> performance penalty. > > I'm still not convinced that this is really the root cause for the > performance issues Jay noticed. AFAIK mac80211 doesn't access the payload > anymore when reporting the frame back (with some exceptions like monitor > interfaces). > > Jay, could you please run a few more performance tests with and without this > patch to track down if this issue is really the cause for the performance > degradation? > >> Basic idea is to no longer work on the original skb that mac80211 >> supplied us, but to >> use a copy of that skb. This would prevent us from having to undo any >> changes we did, >> as we can simply return the original skb to mac80211 (which wasn't >> modified in the first >> place). >> I'm not sure how this would impact performance, but it would allow us >> a lot less copying >> around to undo the changes done before uploading to the HW. > > But cloning the skb would double the amount of memory needed to transmit each > frame. Not sure though if that behaves better or not. Might be worth a try. > >> However, I won't be able to look into that opportunity before the weekend. >> >> Helmut, can you wait that long and hold off reverting until then? > OK. Find attached the patch I cooked up. AFAICS the driver still works correctly, but unfortunately I am unable to test performance and throughput of the driver with this patch. Jay and Helmut, can you test this patch before I submit it? --- Gertjan.