From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85200C31E46 for ; Wed, 12 Jun 2019 10:58:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 661352080A for ; Wed, 12 Jun 2019 10:58:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732328AbfFLK6H (ORCPT ); Wed, 12 Jun 2019 06:58:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55760 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728127AbfFLK6H (ORCPT ); Wed, 12 Jun 2019 06:58:07 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C331A316290B; Wed, 12 Jun 2019 10:58:06 +0000 (UTC) Received: from localhost (unknown [10.43.2.57]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6850C7BE8F; Wed, 12 Jun 2019 10:58:04 +0000 (UTC) Date: Wed, 12 Jun 2019 12:58:02 +0200 From: Stanislaw Gruszka To: Lorenzo Bianconi Cc: Lorenzo Bianconi , nbd@nbd.name, kvalo@codeaurora.org, linux-wireless@vger.kernel.org Subject: Re: [PATCH v2 1/2] mt76: usb: fix rx A-MSDU support Message-ID: <20190612105801.GA2600@redhat.com> References: <52ea155d9889aa15df44b4910806b74fa2fd9056.1559293385.git.lorenzo@kernel.org> <20190612085844.GA2965@redhat.com> <20190612094519.GC8107@localhost.localdomain> <20190612100014.GA4431@redhat.com> <20190612102133.GE8107@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190612102133.GE8107@localhost.localdomain> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.41]); Wed, 12 Jun 2019 10:58:06 +0000 (UTC) Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org 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. > > > > 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? Stanislaw