Re: extending feature word.

[Mahesh Bandewar <maheshb@google.com>]

On Mon, Apr 11, 2011 at 11:54 AM, Stephen Hemminger
<shemminger@vyatta.com> wrote:
> On Mon, 11 Apr 2011 11:45:05 -0700
> Mahesh Bandewar <maheshb@google.com> wrote:
>
>> >> That is right! making it an array doesn't really buy us anything
>> >> unless there is a uniform way of managing all the bits spread across
>> >> multiple words inside that array. This was the reason why I have
>> >> changed that array into a bitmap in the patch that I have posted
>> >> earlier. This way the upper limit (currently only 32 bits) will be
>> >> removed and we'll have a long term solution. There will be little bit
>> >> of work involved but 'doing-things-right' has cost associated.
>> >
>> > I really don't like the bitmap idea. It multiplies the amount of code
>> > needed to manipulate multiple bits at once --- and that's a common
>> > thing for drivers to do. Almost every driver that needs ndo_fix_features
>> > will clear sets --- checkumming set, TSO set, all TX offloads set, ...
>> >
>> Should the added code be of any concern? If that is happening in the
>> control-path and does not affect the data-path as such; those added
>> instructions is a cost of added flexibility to we got through bitmap.
>> If performance is not at risk then that shouldn't be a problem.
>
> Just to be dense... What is wrong with just using u64?
>
I have already suggested that in this thread. With this theoretically
you removing one limit and imposing another and that's why I said it
would be a mid-term solution. But again by the time all 64 bits are
gone (got used), we may have u128 available.

> --
>