[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110411115459.13ac3c73@nehalam>
Date: Mon, 11 Apr 2011 11:54:59 -0700
From: Stephen Hemminger <shemminger@...tta.com>
To: Mahesh Bandewar <maheshb@...gle.com>
Cc: Michał Mirosław <mirq-linux@...e.qmqm.pl>,
linux-netdev <netdev@...r.kernel.org>,
Ben Hutchings <bhutchings@...arflare.com>,
David Miller <davem@...emloft.net>
Subject: Re: extending feature word.
On Mon, 11 Apr 2011 11:45:05 -0700
Mahesh Bandewar <maheshb@...gle.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?
--
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists