Message ID | 20220918094336.28958-1-shenjian15@huawei.com (mailing list archive) |
---|---|
Headers | show |
Series | net: extend the type of netdev_features_t to bitmap | expand |
On Sun, 18 Sep 2022 09:42:41 +0000 Jian Shen wrote: > 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. For v9 could you filter out all the driver changes? Focus on adding the helpers and converting core (excluding tunnel drivers etc.) in a way that will not break the build. That way we can iterate on the revisions more quickly, hopefully, and convert the drivers once we have the helpers ironed out?
From: Jian Shen <shenjian15@huawei.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? [...] > -- > 2.33.0 Thanks, Olek
在 2022/11/25 23:44, Alexander Lobakin 写道: > From: Jian Shen <shenjian15@huawei.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. Btw, could you kindly review this V8 set? I have adjusted the protocol of many interfaces and helpers, to avoiding return or pass data large than 64bits. Hope to get more opinions. Thanks! Jian >> -- >> 2.33.0 > Thanks, > Olek > . >
From: "shenjian (K)" <shenjian15@huawei.com> Date: Mon, 28 Nov 2022 23:22:28 +0800 > 2022/11/25 23:44, Alexander Lobakin: > > From: Jian Shen <shenjian15@huawei.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 > > 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
From: Alexander Lobakin <alexandr.lobakin@intel.com> Date: Mon, 28 Nov 2022 16:51:27 +0100 > From: "shenjian (K)" <shenjian15@huawei.com> > Date: Mon, 28 Nov 2022 23:22:28 +0800 > >> 2022/11/25 23:44, Alexander Lobakin: >>> From: Jian Shen <shenjian15@huawei.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? > >> >> 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
在 2023/9/13 18:28, Alexander Lobakin 写道: > From: Alexander Lobakin <alexandr.lobakin@intel.com> > Date: Mon, 28 Nov 2022 16:51:27 +0100 > >> From: "shenjian (K)" <shenjian15@huawei.com> >> Date: Mon, 28 Nov 2022 23:22:28 +0800 >> >>> 2022/11/25 23:44, Alexander Lobakin: >>>> From: Jian Shen <shenjian15@huawei.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 > . >
From: Shenjian (K) <shenjian15@huawei.com> Date: Sat, 16 Sep 2023 15:20:27 +0800 > > > 在 2023/9/13 18:28, Alexander Lobakin 写道: >> From: Alexander Lobakin <alexandr.lobakin@intel.com> >> Date: Mon, 28 Nov 2022 16:51:27 +0100 >> >>> From: "shenjian (K)" <shenjian15@huawei.com> >>> Date: Mon, 28 Nov 2022 23:22:28 +0800 >>> >>>> 2022/11/25 23:44, Alexander Lobakin: >>>>> From: Jian Shen <shenjian15@huawei.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. Oh well, I'm kinda overloaded as well (as always) and at the same time won't work with the code during the next month due to conferences and a vacation :z :D Would I take this project over, I'd start working on it no sooner than January 2024, so I don't think that would be a good idea. Anyone else? +Cc Sabrina, there's "netdev_features_t extension" mentioned next to her name in one interesting spreadsheet :D > > Jian [...] Thanks, Olek
On Mon, 18 Sep 2023 16:25:14 +0200 Alexander Lobakin wrote: > > 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. > > Oh well, I'm kinda overloaded as well (as always) and at the same time > won't work with the code during the next month due to conferences and > a vacation :z :D > Would I take this project over, I'd start working on it no sooner than > January 2024, so I don't think that would be a good idea. > > Anyone else? +Cc Sabrina, there's "netdev_features_t extension" > mentioned next to her name in one interesting spreadsheet :D FTR Olek brought this topic up at netconf and the conclusion/Eric's guidance was to deprioritize this work. Instead focus on cleaning up things which are currently in features but do no need to be accessed in generic fast paths.