[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1294248486.15866.88.camel@bwh-desktop>
Date: Wed, 05 Jan 2011 17:28:06 +0000
From: Ben Hutchings <bhutchings@...arflare.com>
To: Alexander Duyck <alexander.h.duyck@...el.com>
Cc: "davem@...emloft.net" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [net-next-2.6 PATCH] ethtool: update get_rx_ntuple to
correctly interpret string count
On Wed, 2011-01-05 at 08:57 -0800, Alexander Duyck wrote:
[...]
> I'm fine with us replacing the ETHTOOL_GRXNTUPLE interface, but I would
> prefer to do it after the merge windows for 2.6.39 has opened. For now
> I would like to get this patch accepted as my main concern is getting a
> minor fix in versus rewriting the entire interface.
So long as there are no in-tree implementations of
ethtool_ops::get_rx_ntuple then it's a valid candidate for removal.
Since you now want to implement it, I think you should submit the
implementation along with the fix for the calling code.
> While we're at it how would you feel about us inverting the masks for
> setting up an ntuple by making them an inclusion mask instead of an
> exclusion one? The reason why I ask is because I have to perform an and
> operation over all the input anyway before I can use it to compute the
> hashes and as such I am having to invert almost all of the mask bits,
> and it appears you are having to do this as well for many of the masks
> in sfc.
We can't change the userland interface but we could potentially invert
the masks in the ethtool core. I'm really not convinced that this is
worth the trouble though. (And it would be a massive pain for the OOT
versions of our drivers.)
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
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