[RFC] ethtool: Expand ethtool_cmd.speed to 32 bits

[RFC] ethtool: Expand ethtool_cmd.speed to 32 bits

[Brandon Philips]

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 {

Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits

[Rick Jones]

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

Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits

[David Miller]

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.

Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits

[David Miller]

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?

Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits

[Brandon Philips]

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

Re: ethtool: Expand ethtool_cmd.speed to 32 bits

[Brandon Philips]

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

Re: ethtool: Expand ethtool_cmd.speed to 32 bits

[Jeff Garzik]

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

Re: [RFC] ethtool: Expand ethtool_cmd.speed to 32 bits

[Jeff Garzik]

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