> On Wed, Jun 12, 2019 at 12:21:34PM +0200, Lorenzo Bianconi wrote:
> > On Jun 12, Stanislaw Gruszka wrote:
> > > On Wed, Jun 12, 2019 at 11:45:21AM +0200, Lorenzo Bianconi wrote:
> > > > > > +mt76u_build_rx_skb(u8 *data, int len, int buf_size,
> > > > > > + int *nsgs)
> > > > > > +{
> > > > > > + int data_len = min(len, MT_SKB_HEAD_LEN);
> > >
> > > Oh, and this looks unneeded as well as for len < MT_SKB_HEAD_LEN=128
> > > we will go through fast path.
> >
> > I guess if we remove data_len = min(len, MT_SKB_HEAD_LEN) and even *nsgs =
> > 0 at
> > the end we are making some assumptions on the value of MT_SKB_HEAD_LEN and
> > buf_size. In the patch I just avoided them but maybe we can just assume that
> > MT_SKB_HEAD_LEN and buf_size will not changed in the future. What do you
> > think?
>
> Yes, sure. Other drivers just use 128 value directly and don't even
> create a macro for that. And if somebody will decide to change
> buf_size it will not be small value.Ok, I will simplify it in v2 > > > > > > mt7601u and iwlmvm just copy hdrlen + 8 and put the rest > > > > > of the buffer in fragment, which supose to be more efficient, > > > > > see comment in iwl_mvm_pass_packet_to_mac80211(). > > > > > > > > Right here we copy 128B instead of 32 but I think it is good to have L3 > > > > and L4 > > > > header in the linear area of the skb since otherwise the stack will > > > > need to > > > > align them > > > > > > Not sure if understand, I think aliment of L3 & L4 headers will be > > > the same, assuming ieee80211 header is aligned the same in fragment > > > buffer and in linear area. But if you think this is better to copy those > > > to linear area I'm ok with that. > > > > Sorry I have not been so clear. I mean in the stack before accessing a given > > header we will run pskb_may_pull() that can end up copying the skb if there > > is > > not enough space in the skb->head > > Ok, so L3 and L4 headers should be in linear area of skb and if not > network stack will copy them from fragment. But I wonder why other > drivers just copy ieee80211_hdr and SNAP ? Isn't that if we copy > 128B then is possible that part of the payload will be in linear > area and part in fragment, whereas is expected that payload > will not be broken into two parts? I think the payload can be split in multiple skb fragments, the constraint is just related to header parsing Regards, Lorenzo > > Stanislaw
signature.asc
Description: PGP signature
