[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0352cd0e-9721-514d-0683-0eed91f711d7@huawei.com>
Date: Sat, 16 Sep 2023 15:20:27 +0800
From: "shenjian (K)" <shenjian15@...wei.com>
To: Alexander Lobakin <aleksander.lobakin@...el.com>
CC: <davem@...emloft.net>, <kuba@...nel.org>, <ecree.xilinx@...il.com>,
<andrew@...n.ch>, <hkallweit1@...il.com>, <saeed@...nel.org>,
<leon@...nel.org>, <netdev@...r.kernel.org>, <linuxarm@...wei.com>
Subject: Re: [RFCv8 PATCH net-next 00/55] net: extend the type of
netdev_features_t to bitmap
在 2023/9/13 18:28, Alexander Lobakin 写道:
> From: Alexander Lobakin <alexandr.lobakin@...el.com>
> Date: Mon, 28 Nov 2022 16:51:27 +0100
>
>> From: "shenjian (K)" <shenjian15@...wei.com>
>> Date: Mon, 28 Nov 2022 23:22:28 +0800
>>
>>> 2022/11/25 23:44, Alexander Lobakin:
>>>> From: Jian Shen <shenjian15@...wei.com>
>>>> Date: Sun, 18 Sep 2022 09:42:41 +0000
>>>>
>>>>> For the prototype of netdev_features_t is u64, and the number
>>>>> of netdevice feature bits is 64 now. So there is no space to
>>>>> introduce new feature bit.
>>>>>
>>>>> This patchset try to solve it by change the prototype of
>>>>> netdev_features_t from u64 to structure below:
>>>>> typedef struct {
>>>>> DECLARE_BITMAP(bits, NETDEV_FEATURE_COUNT);
>>>>> } netdev_features_t;
>>>>>
>>>>> With this change, it's necessary to introduce a set of bitmap
>>>>> operation helpers for netdev features. [patch 1]
>>>> Hey,
>>>>
>>>> what's the current status, how's going?
>>>>
>>>> [...]
>>> Hi, Alexander
>>>
>>> Sorry to reply late, I'm still working on this, dealing with split the
>>> patchset.
>> Hey, no worries. Just curious as I believe lots of new features are
>> waiting for new bits to be available :D
> Hey,
>
> Any news?
Sorry, Olek .
Would you like to continue the work ? I thought I could finish this work
as soon as possible, but in fact, there is a serious time conflict.
Jian
>>> Btw, could you kindly review this V8 set? I have adjusted the protocol
>>> of many interfaces and helpers,
>> I'll try to find some time to review it this week, will see.
>>
>>> to avoiding return or pass data large than 64bits. Hope to get more
>> Yes, I'd prefer to not pass more than 64 bits in one function
>> argument, which means functions operating with netdev_features_t
>> must start take pointers. Otherwise, with passing netdev_features_t
>> directly as a struct, the very first newly added feature will do
>> 8 -> 16 bytes on the stack per argument, boom.
>>
>>> opinions.
>>>
>>> Thanks!
>>>
>>> Jian
>>>>> --
>>>>> 2.33.0
>>>> Thanks,
>>>> Olek
>> Thanks,
>> Olek
> Thanks,
> Olek
> .
>
Powered by blists - more mailing lists