On Wed, Jun 12, 2019 at 04:27:42PM +0200, Lorenzo Bianconi wrote: > > On Wed, Jun 12, 2019 at 02:28:48PM +0200, Lorenzo Bianconi wrote: > > [...] > > > > > > > using sg buffers we can support bigger rx AMSDU size in the future > > > without using > > > huge buffers (e.g. we can try to use IEEE80211_MAX_MPDU_LEN_HT_7935 with > > > mt76x2u) > > I think it would be simpler just to allocate 2 pages for 7935B . > > > > We should avoid increasing buffer size to more than PAGE_SIZE for > performance reasons.
Interesting, at what place and how this affect performance negatively ? > As suggested by Felix what about of setting buf_size to > PAGE_SIZE for both sg and non-sg cases and for sg setting usb data size to > > SKB_WITH_OVERHEAD(q->buf_size) & (usb_endpoint_maxp() - 1); Increasing to PAGE_SIZE for sg looks reasonable to me. Not sure if understand data_size logic. If this mean 'PAGE_SIZE - usb_endpint_maxp()', looks ok to me as well (for first segment), but would require one extra segment to avoid coping (i.e. 2 pages for 3839 , 3 pages for 7935 ...) If we would like to stay with 128B copy fallback, we can have 1 page for 3839 , 2 for 7935 ... It would be interesting how frequently AMSDU of max size is sent by remote station. If this is rare situation I would be opting for smaller allocation and 128B copy fallback. If this is frequent for bigger allocation to assure we can always use build_skb(). Stanislaw
