netdev - Re: extending feature word.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Mon, 11 Apr 2011 12:49:27 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	Michał Mirosław <mirq-linux@...e.qmqm.pl>
Cc:	Mahesh Bandewar <maheshb@...gle.com>,
	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 21:19:47 +0200
Michał Mirosław <mirq-linux@...e.qmqm.pl> wrote:

> On Mon, Apr 11, 2011 at 11:54:59AM -0700, Stephen Hemminger wrote:
> > 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?
> 
> Hmm. Looks like this is so simple that nobody thought of it seriously. ;)
> 
> This of course needs a bit of glue code in G/SFEATURES handling, but most
> of the change would be s/u32/u64/ in apropriate places.

I am a strong proponent of not building stuff until it is needed.
  http://www.extremeprogramming.org/rules/early.html
By the time 64 bits are exhausted the existing model of network device
may have changed significantly anyway.
  
--
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