* [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits
@ 2008-07-15 9:18 Brandon Philips
2008-07-15 21:53 ` Rick Jones
2008-08-07 6:24 ` [RFC] " Jeff Garzik
0 siblings, 2 replies; 8+ messages in thread
From: Brandon Philips @ 2008-07-15 9:18 UTC (permalink / raw)
To: Jeff Garzik, David S. Miller; +Cc: netdev
Introduce the speed_hi field to ethtool_cmd, using the reserved space,
to expand the speed field to 2^32 Megabits/second.
Making this field expansion now gives us plenty of time to fix up the
user-space pieces that use SIOCETHTOOL before hardware faster than 64
Gb/s is available.
Signed-off-by: Brandon Philips <bphilips@suse.de>
---
include/linux/ethtool.h | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
Index: linux-2.6/include/linux/ethtool.h
===================================================================
--- linux-2.6.orig/include/linux/ethtool.h
+++ linux-2.6/include/linux/ethtool.h
@@ -27,9 +27,24 @@ struct ethtool_cmd {
__u8 autoneg; /* Enable or disable autonegotiation */
__u32 maxtxpkt; /* Tx pkts before generating tx int */
__u32 maxrxpkt; /* Rx pkts before generating rx int */
- __u32 reserved[4];
+ __u16 speed_hi;
+ __u16 reserved2;
+ __u32 reserved[3];
};
+static inline void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
+ __u32 speed)
+{
+
+ ep->speed = (__u16)speed;
+ ep->speed_hi = (__u16)(speed >> 16);
+}
+
+static inline __u32 ethtool_cmd_speed(struct ethtool_cmd *ep)
+{
+ return (ep->speed_hi << 16) | ep->speed;
+}
+
#define ETHTOOL_BUSINFO_LEN 32
/* these strings are set to whatever the driver author decides... */
struct ethtool_drvinfo {
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits
2008-07-15 9:18 [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits Brandon Philips
@ 2008-07-15 21:53 ` Rick Jones
2008-07-15 22:27 ` David Miller
2008-08-07 6:24 ` [RFC] " Jeff Garzik
1 sibling, 1 reply; 8+ messages in thread
From: Rick Jones @ 2008-07-15 21:53 UTC (permalink / raw)
To: Brandon Philips; +Cc: Jeff Garzik, David S. Miller, netdev
Brandon Philips wrote:
> Introduce the speed_hi field to ethtool_cmd, using the reserved space,
> to expand the speed field to 2^32 Megabits/second.
>
> Making this field expansion now gives us plenty of time to fix up the
> user-space pieces that use SIOCETHTOOL before hardware faster than 64
> Gb/s is available.
>
> Signed-off-by: Brandon Philips <bphilips@suse.de>
>
> ---
> include/linux/ethtool.h | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/include/linux/ethtool.h
> ===================================================================
> --- linux-2.6.orig/include/linux/ethtool.h
> +++ linux-2.6/include/linux/ethtool.h
> @@ -27,9 +27,24 @@ struct ethtool_cmd {
> __u8 autoneg; /* Enable or disable autonegotiation */
> __u32 maxtxpkt; /* Tx pkts before generating tx int */
> __u32 maxrxpkt; /* Rx pkts before generating rx int */
> - __u32 reserved[4];
> + __u16 speed_hi;
> + __u16 reserved2;
> + __u32 reserved[3];
> };
I certainly agree with the concept of preparing for faster NICs. Are
bits in that structure sufficiently precious to go the split route, or
would it be cleaner to just grab a contiguous 32 bits from the structure?
rick jones
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits
2008-07-15 21:53 ` Rick Jones
@ 2008-07-15 22:27 ` David Miller
2008-07-16 6:47 ` Brandon Philips
0 siblings, 1 reply; 8+ messages in thread
From: David Miller @ 2008-07-15 22:27 UTC (permalink / raw)
To: rick.jones2; +Cc: brandon, jgarzik, netdev
From: Rick Jones <rick.jones2@hp.com>
Date: Tue, 15 Jul 2008 14:53:16 -0700
> Brandon Philips wrote:
> > Introduce the speed_hi field to ethtool_cmd, using the reserved space,
> > to expand the speed field to 2^32 Megabits/second.
> >
> > Making this field expansion now gives us plenty of time to fix up the
> > user-space pieces that use SIOCETHTOOL before hardware faster than 64
> > Gb/s is available.
> >
> > Signed-off-by: Brandon Philips <bphilips@suse.de>
> >
> > ---
> > include/linux/ethtool.h | 17 ++++++++++++++++-
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > Index: linux-2.6/include/linux/ethtool.h
> > ===================================================================
> > --- linux-2.6.orig/include/linux/ethtool.h
> > +++ linux-2.6/include/linux/ethtool.h
> > @@ -27,9 +27,24 @@ struct ethtool_cmd {
> > __u8 autoneg; /* Enable or disable autonegotiation */
> > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > - __u32 reserved[4];
> > + __u16 speed_hi;
> > + __u16 reserved2;
> > + __u32 reserved[3];
> > };
>
> I certainly agree with the concept of preparing for faster NICs. Are
> bits in that structure sufficiently precious to go the split route, or
> would it be cleaner to just grab a contiguous 32 bits from the structure?
That's less space we can use to make similar expansions.
And we have to keep the existing u16 chunk there anyways, because existing
applications are only going to provide that part.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits
2008-07-15 22:27 ` David Miller
@ 2008-07-16 6:47 ` Brandon Philips
2008-07-15 22:43 ` David Miller
0 siblings, 1 reply; 8+ messages in thread
From: Brandon Philips @ 2008-07-16 6:47 UTC (permalink / raw)
To: David Miller; +Cc: rick.jones2, jgarzik, netdev
On 15:27 Tue 15 Jul 2008, David Miller wrote:
> From: Rick Jones <rick.jones2@hp.com>
> Date: Tue, 15 Jul 2008 14:53:16 -0700
>
> > Brandon Philips wrote:
> > > Introduce the speed_hi field to ethtool_cmd, using the reserved space,
> > > to expand the speed field to 2^32 Megabits/second.
> > >
> > > Making this field expansion now gives us plenty of time to fix up the
> > > user-space pieces that use SIOCETHTOOL before hardware faster than 64
> > > Gb/s is available.
> > >
> > > Signed-off-by: Brandon Philips <bphilips@suse.de>
> > >
> > > ---
> > > include/linux/ethtool.h | 17 ++++++++++++++++-
> > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > >
> > > Index: linux-2.6/include/linux/ethtool.h
> > > ===================================================================
> > > --- linux-2.6.orig/include/linux/ethtool.h
> > > +++ linux-2.6/include/linux/ethtool.h
> > > @@ -27,9 +27,24 @@ struct ethtool_cmd {
> > > __u8 autoneg; /* Enable or disable autonegotiation */
> > > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > > - __u32 reserved[4];
> > > + __u16 speed_hi;
> > > + __u16 reserved2;
> > > + __u32 reserved[3];
> > > };
> >
> > I certainly agree with the concept of preparing for faster NICs. Are
> > bits in that structure sufficiently precious to go the split route, or
> > would it be cleaner to just grab a contiguous 32 bits from the structure?
>
> That's less space we can use to make similar expansions.
>
> And we have to keep the existing u16 chunk there anyways, because existing
> applications are only going to provide that part.
Agreed. Can this be queued for 2.6.27 then?
Thanks,
Brandon
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits
2008-07-16 6:47 ` Brandon Philips
@ 2008-07-15 22:43 ` David Miller
2008-07-28 17:11 ` Brandon Philips
0 siblings, 1 reply; 8+ messages in thread
From: David Miller @ 2008-07-15 22:43 UTC (permalink / raw)
To: brandon; +Cc: rick.jones2, jgarzik, netdev
From: Brandon Philips <brandon@ifup.org>
Date: Tue, 15 Jul 2008 23:47:09 -0700
> On 15:27 Tue 15 Jul 2008, David Miller wrote:
> > From: Rick Jones <rick.jones2@hp.com>
> > Date: Tue, 15 Jul 2008 14:53:16 -0700
> >
> > > Brandon Philips wrote:
> > > > Introduce the speed_hi field to ethtool_cmd, using the reserved space,
> > > > to expand the speed field to 2^32 Megabits/second.
> > > >
> > > > Making this field expansion now gives us plenty of time to fix up the
> > > > user-space pieces that use SIOCETHTOOL before hardware faster than 64
> > > > Gb/s is available.
> > > >
> > > > Signed-off-by: Brandon Philips <bphilips@suse.de>
> > > >
> > > > ---
> > > > include/linux/ethtool.h | 17 ++++++++++++++++-
> > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > >
> > > > Index: linux-2.6/include/linux/ethtool.h
> > > > ===================================================================
> > > > --- linux-2.6.orig/include/linux/ethtool.h
> > > > +++ linux-2.6/include/linux/ethtool.h
> > > > @@ -27,9 +27,24 @@ struct ethtool_cmd {
> > > > __u8 autoneg; /* Enable or disable autonegotiation */
> > > > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > > > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > > > - __u32 reserved[4];
> > > > + __u16 speed_hi;
> > > > + __u16 reserved2;
> > > > + __u32 reserved[3];
> > > > };
> > >
> > > I certainly agree with the concept of preparing for faster NICs. Are
> > > bits in that structure sufficiently precious to go the split route, or
> > > would it be cleaner to just grab a contiguous 32 bits from the structure?
> >
> > That's less space we can use to make similar expansions.
> >
> > And we have to keep the existing u16 chunk there anyways, because existing
> > applications are only going to provide that part.
>
> Agreed. Can this be queued for 2.6.27 then?
Jeff?
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: ethtool: Expand ethtool_cmd.speed to 32 bits
2008-07-15 22:43 ` David Miller
@ 2008-07-28 17:11 ` Brandon Philips
2008-07-28 18:36 ` Jeff Garzik
0 siblings, 1 reply; 8+ messages in thread
From: Brandon Philips @ 2008-07-28 17:11 UTC (permalink / raw)
To: David Miller, Jeff Garzik; +Cc: rick.jones2, netdev, jgarzik
On 15:43 Tue 15 Jul 2008, David Miller wrote:
> From: Brandon Philips <brandon@ifup.org>
> Date: Tue, 15 Jul 2008 23:47:09 -0700
>
> > On 15:27 Tue 15 Jul 2008, David Miller wrote:
> > > From: Rick Jones <rick.jones2@hp.com>
> > > Date: Tue, 15 Jul 2008 14:53:16 -0700
> > >
> > > > Brandon Philips wrote:
> > > > > Introduce the speed_hi field to ethtool_cmd, using the reserved space,
> > > > > to expand the speed field to 2^32 Megabits/second.
> > > > >
> > > > > Making this field expansion now gives us plenty of time to fix up the
> > > > > user-space pieces that use SIOCETHTOOL before hardware faster than 64
> > > > > Gb/s is available.
> > > > >
> > > > > Signed-off-by: Brandon Philips <bphilips@suse.de>
> > > > >
> > > > > ---
> > > > > include/linux/ethtool.h | 17 ++++++++++++++++-
> > > > > 1 file changed, 16 insertions(+), 1 deletion(-)
> > > > >
> > > > > Index: linux-2.6/include/linux/ethtool.h
> > > > > ===================================================================
> > > > > --- linux-2.6.orig/include/linux/ethtool.h
> > > > > +++ linux-2.6/include/linux/ethtool.h
> > > > > @@ -27,9 +27,24 @@ struct ethtool_cmd {
> > > > > __u8 autoneg; /* Enable or disable autonegotiation */
> > > > > __u32 maxtxpkt; /* Tx pkts before generating tx int */
> > > > > __u32 maxrxpkt; /* Rx pkts before generating rx int */
> > > > > - __u32 reserved[4];
> > > > > + __u16 speed_hi;
> > > > > + __u16 reserved2;
> > > > > + __u32 reserved[3];
> > > > > };
> > > >
> > > > I certainly agree with the concept of preparing for faster NICs. Are
> > > > bits in that structure sufficiently precious to go the split route, or
> > > > would it be cleaner to just grab a contiguous 32 bits from the structure?
> > >
> > > That's less space we can use to make similar expansions.
> > >
> > > And we have to keep the existing u16 chunk there anyways, because existing
> > > applications are only going to provide that part.
> >
> > Agreed. Can this be queued for 2.6.27 then?
>
> Jeff?
Has this been merged somewhere? I just checked net-2.6 and net-next and
didn't see it.
Thanks,
Brandon
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: ethtool: Expand ethtool_cmd.speed to 32 bits
2008-07-28 17:11 ` Brandon Philips
@ 2008-07-28 18:36 ` Jeff Garzik
0 siblings, 0 replies; 8+ messages in thread
From: Jeff Garzik @ 2008-07-28 18:36 UTC (permalink / raw)
To: Brandon Philips; +Cc: David Miller, rick.jones2, netdev, jgarzik
Brandon Philips wrote:
> On 15:43 Tue 15 Jul 2008, David Miller wrote:
>> From: Brandon Philips <brandon@ifup.org>
>> Date: Tue, 15 Jul 2008 23:47:09 -0700
>>
>>> On 15:27 Tue 15 Jul 2008, David Miller wrote:
>>>> From: Rick Jones <rick.jones2@hp.com>
>>>> Date: Tue, 15 Jul 2008 14:53:16 -0700
>>>>
>>>>> Brandon Philips wrote:
>>>>>> Introduce the speed_hi field to ethtool_cmd, using the reserved space,
>>>>>> to expand the speed field to 2^32 Megabits/second.
>>>>>>
>>>>>> Making this field expansion now gives us plenty of time to fix up the
>>>>>> user-space pieces that use SIOCETHTOOL before hardware faster than 64
>>>>>> Gb/s is available.
>>>>>>
>>>>>> Signed-off-by: Brandon Philips <bphilips@suse.de>
>>>>>>
>>>>>> ---
>>>>>> include/linux/ethtool.h | 17 ++++++++++++++++-
>>>>>> 1 file changed, 16 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> Index: linux-2.6/include/linux/ethtool.h
>>>>>> ===================================================================
>>>>>> --- linux-2.6.orig/include/linux/ethtool.h
>>>>>> +++ linux-2.6/include/linux/ethtool.h
>>>>>> @@ -27,9 +27,24 @@ struct ethtool_cmd {
>>>>>> __u8 autoneg; /* Enable or disable autonegotiation */
>>>>>> __u32 maxtxpkt; /* Tx pkts before generating tx int */
>>>>>> __u32 maxrxpkt; /* Rx pkts before generating rx int */
>>>>>> - __u32 reserved[4];
>>>>>> + __u16 speed_hi;
>>>>>> + __u16 reserved2;
>>>>>> + __u32 reserved[3];
>>>>>> };
>>>>> I certainly agree with the concept of preparing for faster NICs. Are
>>>>> bits in that structure sufficiently precious to go the split route, or
>>>>> would it be cleaner to just grab a contiguous 32 bits from the structure?
>>>> That's less space we can use to make similar expansions.
>>>>
>>>> And we have to keep the existing u16 chunk there anyways, because existing
>>>> applications are only going to provide that part.
>>> Agreed. Can this be queued for 2.6.27 then?
>> Jeff?
>
> Has this been merged somewhere? I just checked net-2.6 and net-next and
> didn't see it.
Sorry, this thread was buried deep in an inbox. Rescued and queued.
Jeff
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits
2008-07-15 9:18 [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits Brandon Philips
2008-07-15 21:53 ` Rick Jones
@ 2008-08-07 6:24 ` Jeff Garzik
1 sibling, 0 replies; 8+ messages in thread
From: Jeff Garzik @ 2008-08-07 6:24 UTC (permalink / raw)
To: Brandon Philips; +Cc: David S. Miller, netdev
Brandon Philips wrote:
> Introduce the speed_hi field to ethtool_cmd, using the reserved space,
> to expand the speed field to 2^32 Megabits/second.
>
> Making this field expansion now gives us plenty of time to fix up the
> user-space pieces that use SIOCETHTOOL before hardware faster than 64
> Gb/s is available.
>
> Signed-off-by: Brandon Philips <bphilips@suse.de>
>
> ---
> include/linux/ethtool.h | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/include/linux/ethtool.h
> ===================================================================
> --- linux-2.6.orig/include/linux/ethtool.h
> +++ linux-2.6/include/linux/ethtool.h
> @@ -27,9 +27,24 @@ struct ethtool_cmd {
> __u8 autoneg; /* Enable or disable autonegotiation */
> __u32 maxtxpkt; /* Tx pkts before generating tx int */
> __u32 maxrxpkt; /* Rx pkts before generating rx int */
> - __u32 reserved[4];
> + __u16 speed_hi;
> + __u16 reserved2;
> + __u32 reserved[3];
> };
>
> +static inline void ethtool_cmd_speed_set(struct ethtool_cmd *ep,
> + __u32 speed)
> +{
> +
> + ep->speed = (__u16)speed;
> + ep->speed_hi = (__u16)(speed >> 16);
> +}
> +
> +static inline __u32 ethtool_cmd_speed(struct ethtool_cmd *ep)
> +{
> + return (ep->speed_hi << 16) | ep->speed;
> +}
> +
applied
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-08-07 6:24 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-15 9:18 [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits Brandon Philips
2008-07-15 21:53 ` Rick Jones
2008-07-15 22:27 ` David Miller
2008-07-16 6:47 ` Brandon Philips
2008-07-15 22:43 ` David Miller
2008-07-28 17:11 ` Brandon Philips
2008-07-28 18:36 ` Jeff Garzik
2008-08-07 6:24 ` [RFC] " Jeff Garzik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).