[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <EDC0E76513226749BFBC9C3FB031318F0173FF8648@orsmsx508.amr.corp.intel.com>
Date: Fri, 2 Sep 2011 14:29:22 -0700
From: "Wyborny, Carolyn" <carolyn.wyborny@...el.com>
To: Michał Mirosław <mirqus@...il.com>
CC: David Miller <davem@...emloft.net>,
"bhutchings@...arflare.com" <bhutchings@...arflare.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [RFC, 1/2] ethtool: Implement private flags interface for
ethtool application.
>-----Original Message-----
>From: Michał Mirosław [mailto:mirqus@...il.com]
>Sent: Friday, September 02, 2011 2:22 PM
>To: Wyborny, Carolyn
>Cc: David Miller; bhutchings@...arflare.com; netdev@...r.kernel.org
>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface for
>ethtool application.
>
>W dniu 2 września 2011 23:17 użytkownik Michał Mirosław
><mirqus@...il.com> napisał:
>> 2011/9/2 Wyborny, Carolyn <carolyn.wyborny@...el.com>:
>>>>-----Original Message-----
>>>>From: David Miller [mailto:davem@...emloft.net]
>>>>Sent: Friday, September 02, 2011 1:55 PM
>>>>To: Wyborny, Carolyn
>>>>Cc: bhutchings@...arflare.com; netdev@...r.kernel.org
>>>>Subject: Re: [RFC, 1/2] ethtool: Implement private flags interface
>for
>>>>ethtool application.
>>>>
>>>>From: Carolyn Wyborny <carolyn.wyborny@...el.com>
>>>>Date: Fri, 2 Sep 2011 13:50:30 -0700
>>>>
>>>>> This patch completes the user space implementation of the private
>>>>> flags inteface in ethtool. Using -b/-B options.
>>>>>
>>>>> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@...el.com>
>>>>
>>>>The only use case you show here is something generic which other
>>>>chips have, Energy Efficient Ethernet.
>>>>
>>>>Making an attribute private which is present widely amonst various
>>>>networking chips makes no sense at all.
>>>>
>>>>It deserved a generic ethtool flag.
>>>
>>> Fair enough on this particular feature, but does that negate the
>implementation suggestion altogether? I can send an updated feature
>implementation for the use case using DMA Coalescing if that will help.
>> I would rather see this as an extension to ETHTOOL_[GS]FEATURES. Its
>> semantics allow easy expanding to handle device-private flags without
>> changing anything on userspace side.
>
>BTW, After pending Intel drivers get converted to ndo_set_features and
>netdev->features get extended to 64 bits, it would also be possible to
>use some of the unused bits there for device/driver-private flags
>almost "for free".
>
>Best Regards,
>Michał Mirosław
That seems reasonable as then there would be room for them, but is it going to be OK to use those unused bits or are they going to be intended for generic features and not device specific ones?
Is the intent then to not ever use the priv_flags partial implementation?
Thanks,
Carolyn
Carolyn Wyborny
Linux Development
LAN Access Division
Intel Corporation
--
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