Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Ganapathi Bhat <ganapathi.bhat@nxp.com>
To:     Brian Norris <briannorris@chromium.org>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
CC:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Nishant Sarmukadam <nishants@marvell.com>,
        Amitkumar Karwar <amitkarwar@gmail.com>,
        Xinming Hu <huxinming820@gmail.com>,
        Arend Van Spriel <arend@broadcom.com>
Subject: RE: [EXT] [PATCH] mwifiex: set needed_headroom, not hard_header_len
Thread-Topic: [EXT] [PATCH] mwifiex: set needed_headroom, not hard_header_len
Thread-Index: AQHV7QGefb0w+LZbCU2BNI3eE64ugag5ZweQ
Date:   Thu, 5 Mar 2020 04:00:42 +0000
Message-ID: <DB7PR04MB524240B38FF6603D89D694538FE20@DB7PR04MB5242.eurprd04.prod.outlook.com>
References: <20200227000511.256055-1-briannorris@chromium.org>
In-Reply-To: <20200227000511.256055-1-briannorris@chromium.org>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 18e32537-b7ae-4ca3-e870-08d7c0b9c640
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2020 04:00:42.2160
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9rNofqnpgZASrhbFcTWgBuoIcyt1IqD6dB6nNLxuWxNMQybkJUAxQLKLQYZE30IBb8kE4Ddher+Q20PpTrcdyA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR04MB3977
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Brian,
=20
> hard_header_len provides limitations for things like AF_PACKET, such that
> we don't allow transmitting packets smaller than this.


OK; However, are we not supposed to mention hard_header_len also?

>=20
> needed_headroom provides a suggested minimum headroom for SKBs, so
> that we can trivally add our headers to the front.
>=20
> The latter is the correct field to use in this case, while the former mos=
tly just
> prevents sending small AF_PACKET frames.
>=20
> In any case, mwifiex already does its own bounce buffering [1] if we don'=
t
> have enough headroom, so hints (not hard limits) are all that are needed.
>=20
> This is the essentially the same bug (and fix) that brcmfmac had, fixed i=
n
> commit cb39288fd6bb ("brcmfmac: use ndev->needed_headroom to reserve
> additional header space").

OK; I read this commit:

"... According to definition of LL_RESERVED_SPACE() and hard_header_len, we=
 should use hard_header_len to reserve for L2 header, like ethernet header(=
ETH_HLEN) in our case and use needed_headroom for the additional headroom n=
eeded by hardware..."

So, does it mean, hard_header_len is already considered by upper layer?


Regards,
Ganapathi