[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20100120.185457.32730304.davem@davemloft.net>
Date: Wed, 20 Jan 2010 18:54:57 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: peter.p.waskiewicz.jr@...el.com
Cc: bhutchings@...arflare.com, jeffrey.t.kirsher@...el.com,
netdev@...r.kernel.org, gospo@...hat.com, deri@...p.org,
joseph.gasparakis@...el.com
Subject: Re: [net-next-2.6 PATCH 3/5] ethtool: Introduce n-tuple filter
programming support
From: "Waskiewicz Jr, Peter P" <peter.p.waskiewicz.jr@...el.com>
Date: Tue, 12 Jan 2010 11:13:54 -0800
>>-----Original Message-----
>>From: Ben Hutchings [mailto:bhutchings@...arflare.com]
>>Sent: Monday, January 11, 2010 11:33 AM
>>To: Kirsher, Jeffrey T
>>Cc: davem@...emloft.net; netdev@...r.kernel.org; gospo@...hat.com;
>>Waskiewicz Jr, Peter P; Luca Deri; Gasparakis, Joseph
>>Subject: Re: [net-next-2.6 PATCH 3/5] ethtool: Introduce n-tuple filter
>>programming support
>>
>>It it really necessary to add new driver operations? It seems to me
>>that it would be preferable to extend {get,set}_rx_nfc() and have the
>>ethtool common code convert between the ethtool_rxnfc and
>>ethtool_rx_ntuple structures. Does that seem possible?
>>
>
> It is possible, but I'm not sure if it's the right way to go. The
> nfc routines are just flipping the various engines on in niu, where
> the ntuple routines are for passing full amounts of data through for
> different filters. Also, I think keeping them separate makes niu
> programming cleaner, which can support both the nfc and ntuple
> modes.
Agreed.
--
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