[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6613f5ae-7f2e-48ea-aa8a-f587ae6688ea@intel.com>
Date: Wed, 26 Jun 2024 10:52:17 +0200
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Eric Dumazet <edumazet@...gle.com>
CC: "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, David Ahern <dsahern@...nel.org>, Xuan Zhuo
<xuanzhuo@...ux.alibaba.com>, Andrew Lunn <andrew@...n.ch>,
<nex.sw.ncis.osdt.itp.upstreaming@...el.com>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 3/5] netdev_features: convert NETIF_F_LLTX to
dev->lltx
From: Eric Dumazet <edumazet@...gle.com>
Date: Tue, 25 Jun 2024 16:00:51 +0200
> On Tue, Jun 25, 2024 at 1:50 PM Alexander Lobakin
> <aleksander.lobakin@...el.com> wrote:
>>
>> NETIF_F_LLTX can't be changed via Ethtool and is not a feature,
>> rather an attribute, very similar to IFF_NO_QUEUE (and hot).
>> Free one netdev_features_t bit and make it a private flag.
>
>> Now the LLTX bit sits in the first ("Tx read-mostly") cacheline
>> next to netdev_ops, so that the start_xmit locking code will
>> potentially read 1 cacheline less, nice.
>
> Are you sure ?
>
> I certainly appreciate the data locality effort but
> dev->features is read anyway in TX fast path from netif_skb_features()
Ah, right. I though netif_skb_features() happens a bit later than locking.
Anyway, this patch is not about cachelines, but freeing 1
netdev_features_t bit. I can remove this paragraph if it may confuse people.
Thanks,
Olek
Powered by blists - more mailing lists