Patchwork Net-ethtool : Allow ethtool to set interface in loopback mode.

login
register
mail settings
Submitter Mahesh Bandewar
Date Nov. 30, 2010, 8 a.m.
Message ID <AANLkTikVaVv4fkLom+NSQgOUzCd2i3mbHkBNQ6PD4d9Y@mail.gmail.com>
Download mbox | patch
Permalink /patch/73581/
State Superseded
Delegated to: David Miller
Headers show

Comments

Mahesh Bandewar - Nov. 30, 2010, 8 a.m.
This patch enables ethtool to set the loopback mode on a given
interface. This is the reworked version of earlier submit (which I
don't have reference to). By configuring the interface in loopback
mode in conjunction with a policy route / rule, a userland application
can stress the egress / ingress path exposing the flows of the change
in progress and potentially help developer(s) understand the impact of
those changes without even sending a packet out on the network.

Following set of commands illustrates one such example -
    a) ifconfig eth1 192.168.1.1
    b) ip -4 rule add from all iif eth1 lookup 250
    c) ip -4 route add local 0/0 dev lo proto kernel scope host table 250
    d) arp -Ds 192.168.1.100 eth1
    e) arp -Ds 192.168.1.200 eth1
    f) sysctl -w net.ipv4.ip_nonlocal_bind=1
    g) sysctl -w net.ipv4.conf.all.accept_local=1
    # Assuming that the machine has 8 cores
    h) taskset 000f netserver -L 192.168.1.200
    i) taskset 00f0 netperf -t TCP_CRR -L 192.168.1.100 -H 192.168.1.200 -l 30

Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
 include/linux/ethtool.h |    4 ++++
 net/core/ethtool.c      |   39 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 43 insertions(+), 0 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Simon Horman - Nov. 30, 2010, 9:48 a.m.
On Tue, Nov 30, 2010 at 12:00:29AM -0800, Mahesh Bandewar wrote:
> This patch enables ethtool to set the loopback mode on a given
> interface. This is the reworked version of earlier submit (which I
> don't have reference to). By configuring the interface in loopback
> mode in conjunction with a policy route / rule, a userland application
> can stress the egress / ingress path exposing the flows of the change
> in progress and potentially help developer(s) understand the impact of
> those changes without even sending a packet out on the network.
> 
> Following set of commands illustrates one such example -
>     a) ifconfig eth1 192.168.1.1

         Given that b) and c) use ip it seems to me that it would
	 make sense to use i for a) too. 

	 ip addr add 192.168.1.1/24 dev eth1

>     b) ip -4 rule add from all iif eth1 lookup 250
>     c) ip -4 route add local 0/0 dev lo proto kernel scope host table 250
>     d) arp -Ds 192.168.1.100 eth1
>     e) arp -Ds 192.168.1.200 eth1
>     f) sysctl -w net.ipv4.ip_nonlocal_bind=1
>     g) sysctl -w net.ipv4.conf.all.accept_local=1
>     # Assuming that the machine has 8 cores
>     h) taskset 000f netserver -L 192.168.1.200
>     i) taskset 00f0 netperf -t TCP_CRR -L 192.168.1.100 -H 192.168.1.200 -l 30
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ben Hutchings - Nov. 30, 2010, 3:01 p.m.
On Tue, 2010-11-30 at 00:00 -0800, Mahesh Bandewar wrote:
> This patch enables ethtool to set the loopback mode on a given
> interface. This is the reworked version of earlier submit (which I
> don't have reference to). By configuring the interface in loopback
> mode in conjunction with a policy route / rule, a userland application
> can stress the egress / ingress path exposing the flows of the change
> in progress and potentially help developer(s) understand the impact of
> those changes without even sending a packet out on the network.

Is the aim to stress the generic egress/ingress code or also to cover
the specific driver in use?

I note that your colleague Laurent Chavey posted a very similar patch
back in April <http://article.gmane.org/gmane.linux.network/157489> but
he emphasised hardware diagnosis.

> Following set of commands illustrates one such example -
>     a) ifconfig eth1 192.168.1.1
>     b) ip -4 rule add from all iif eth1 lookup 250
>     c) ip -4 route add local 0/0 dev lo proto kernel scope host table 250
>     d) arp -Ds 192.168.1.100 eth1
>     e) arp -Ds 192.168.1.200 eth1
>     f) sysctl -w net.ipv4.ip_nonlocal_bind=1
>     g) sysctl -w net.ipv4.conf.all.accept_local=1
>     # Assuming that the machine has 8 cores
>     h) taskset 000f netserver -L 192.168.1.200
>     i) taskset 00f0 netperf -t TCP_CRR -L 192.168.1.100 -H 192.168.1.200 -l 30
> 
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> ---
>  include/linux/ethtool.h |    4 ++++
>  net/core/ethtool.c      |   39 +++++++++++++++++++++++++++++++++++++++
>  2 files changed, 43 insertions(+), 0 deletions(-)
> 
> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> index 6628a50..7523d45 100644
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -678,6 +678,8 @@ struct ethtool_ops {
>                                   struct ethtool_rxfh_indir *);
>         int     (*set_rxfh_indir)(struct net_device *,
>                                   const struct ethtool_rxfh_indir *);
> +       int     (*get_loopback)(struct net_device *, u32 *);
> +       int     (*set_loopback)(struct net_device *, u32);
>  };
>  #endif /* __KERNEL__ */
> 
> @@ -741,6 +743,8 @@ struct ethtool_ops {
>  #define ETHTOOL_GSSET_INFO     0x00000037 /* Get string set info */
>  #define ETHTOOL_GRXFHINDIR     0x00000038 /* Get RX flow hash indir'n table */
>  #define ETHTOOL_SRXFHINDIR     0x00000039 /* Set RX flow hash indir'n table */
> +#define ETHTOOL_SLOOPBACK      0x0000003a /* Enable / Disable Loopback */
[...]

Where should loopback be done, when enabled?  As near as possible to the
host, so it only covers the DMA engines, or as far away as possible, so
it covers most of the MAC/PHY hardware?

Ben.
Mahesh Bandewar - Nov. 30, 2010, 7:05 p.m.
On Tue, Nov 30, 2010 at 7:01 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
>
> On Tue, 2010-11-30 at 00:00 -0800, Mahesh Bandewar wrote:
> > This patch enables ethtool to set the loopback mode on a given
> > interface. This is the reworked version of earlier submit (which I
> > don't have reference to). By configuring the interface in loopback
> > mode in conjunction with a policy route / rule, a userland application
> > can stress the egress / ingress path exposing the flows of the change
> > in progress and potentially help developer(s) understand the impact of
> > those changes without even sending a packet out on the network.
>
> Is the aim to stress the generic egress/ingress code or also to cover
> the specific driver in use?
>
The idea is to stress maximum egress / ingress path, so if possible
include the driver portion of that path too.

> I note that your colleague Laurent Chavey posted a very similar patch
> back in April <http://article.gmane.org/gmane.linux.network/157489> but
> he emphasised hardware diagnosis.
>
Hardware diagnostic folks are also welcome to use it if they find it
useful apart
from the tools they already have. :)

> > Following set of commands illustrates one such example -
> >     a) ifconfig eth1 192.168.1.1
> >     b) ip -4 rule add from all iif eth1 lookup 250
> >     c) ip -4 route add local 0/0 dev lo proto kernel scope host table 250
> >     d) arp -Ds 192.168.1.100 eth1
> >     e) arp -Ds 192.168.1.200 eth1
> >     f) sysctl -w net.ipv4.ip_nonlocal_bind=1
> >     g) sysctl -w net.ipv4.conf.all.accept_local=1
> >     # Assuming that the machine has 8 cores
> >     h) taskset 000f netserver -L 192.168.1.200
> >     i) taskset 00f0 netperf -t TCP_CRR -L 192.168.1.100 -H 192.168.1.200 -l 30
> >
> > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> > ---
> >  include/linux/ethtool.h |    4 ++++
> >  net/core/ethtool.c      |   39 +++++++++++++++++++++++++++++++++++++++
> >  2 files changed, 43 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > index 6628a50..7523d45 100644
> > --- a/include/linux/ethtool.h
> > +++ b/include/linux/ethtool.h
> > @@ -678,6 +678,8 @@ struct ethtool_ops {
> >                                   struct ethtool_rxfh_indir *);
> >         int     (*set_rxfh_indir)(struct net_device *,
> >                                   const struct ethtool_rxfh_indir *);
> > +       int     (*get_loopback)(struct net_device *, u32 *);
> > +       int     (*set_loopback)(struct net_device *, u32);
> >  };
> >  #endif /* __KERNEL__ */
> >
> > @@ -741,6 +743,8 @@ struct ethtool_ops {
> >  #define ETHTOOL_GSSET_INFO     0x00000037 /* Get string set info */
> >  #define ETHTOOL_GRXFHINDIR     0x00000038 /* Get RX flow hash indir'n table */
> >  #define ETHTOOL_SRXFHINDIR     0x00000039 /* Set RX flow hash indir'n table */
> > +#define ETHTOOL_SLOOPBACK      0x0000003a /* Enable / Disable Loopback */
> [...]
>
> Where should loopback be done, when enabled?  As near as possible to the
> host, so it only covers the DMA engines, or as far away as possible, so
> it covers most of the MAC/PHY hardware?
>
Putting it very close to the HW would stress the maximum soft path and
would make it
beneficial to more people / developers. I understand that capabilities
offered by different
NIC vendors vary so it's little difficult to draw the line as to where
it  should be done. So
if the theme to "maximize the soft path" is maintained, we can leave
it to the individual
driver(s) to maximize the value in offering.

--mahesh..

> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ben Hutchings - Nov. 30, 2010, 7:15 p.m.
On Tue, 2010-11-30 at 11:05 -0800, Mahesh Bandewar wrote:
> On Tue, Nov 30, 2010 at 7:01 AM, Ben Hutchings
> <bhutchings@solarflare.com> wrote:
[...]
> > > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
> > > index 6628a50..7523d45 100644
> > > --- a/include/linux/ethtool.h
> > > +++ b/include/linux/ethtool.h
> > > @@ -678,6 +678,8 @@ struct ethtool_ops {
> > >                                   struct ethtool_rxfh_indir *);
> > >         int     (*set_rxfh_indir)(struct net_device *,
> > >                                   const struct ethtool_rxfh_indir *);
> > > +       int     (*get_loopback)(struct net_device *, u32 *);
> > > +       int     (*set_loopback)(struct net_device *, u32);
> > >  };
> > >  #endif /* __KERNEL__ */
> > >
> > > @@ -741,6 +743,8 @@ struct ethtool_ops {
> > >  #define ETHTOOL_GSSET_INFO     0x00000037 /* Get string set info */
> > >  #define ETHTOOL_GRXFHINDIR     0x00000038 /* Get RX flow hash indir'n table */
> > >  #define ETHTOOL_SRXFHINDIR     0x00000039 /* Set RX flow hash indir'n table */
> > > +#define ETHTOOL_SLOOPBACK      0x0000003a /* Enable / Disable Loopback */
> > [...]
> >
> > Where should loopback be done, when enabled?  As near as possible to the
> > host, so it only covers the DMA engines, or as far away as possible, so
> > it covers most of the MAC/PHY hardware?
> >
> Putting it very close to the HW would stress the maximum soft path and
> would make it
> beneficial to more people / developers. I understand that capabilities
> offered by different
> NIC vendors vary so it's little difficult to draw the line as to where
> it  should be done.

Of course, that's why I suggest 'as near/far as possible' rather than
trying to specify the exact point at which loopback would be enabled.

> So
> if the theme to "maximize the soft path" is maintained, we can leave
> it to the individual
> driver(s) to maximize the value in offering.

I think this should be specified, otherwise measurements on different
types of NIC will not be comparable.  The ethtool API suffers greatly
from losse specification and resulting inconsistency between drivers.
So please add the comment that loopback should be enabled as near to the
host as possible.

Ben.
Mahesh Bandewar - Nov. 30, 2010, 9:22 p.m.
On Tue, Nov 30, 2010 at 11:15 AM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Tue, 2010-11-30 at 11:05 -0800, Mahesh Bandewar wrote:
>> On Tue, Nov 30, 2010 at 7:01 AM, Ben Hutchings
>> <bhutchings@solarflare.com> wrote:
> [...]
>> > > diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> > > index 6628a50..7523d45 100644
>> > > --- a/include/linux/ethtool.h
>> > > +++ b/include/linux/ethtool.h
>> > > @@ -678,6 +678,8 @@ struct ethtool_ops {
>> > >                                   struct ethtool_rxfh_indir *);
>> > >         int     (*set_rxfh_indir)(struct net_device *,
>> > >                                   const struct ethtool_rxfh_indir *);
>> > > +       int     (*get_loopback)(struct net_device *, u32 *);
>> > > +       int     (*set_loopback)(struct net_device *, u32);
>> > >  };
>> > >  #endif /* __KERNEL__ */
>> > >
>> > > @@ -741,6 +743,8 @@ struct ethtool_ops {
>> > >  #define ETHTOOL_GSSET_INFO     0x00000037 /* Get string set info */
>> > >  #define ETHTOOL_GRXFHINDIR     0x00000038 /* Get RX flow hash indir'n table */
>> > >  #define ETHTOOL_SRXFHINDIR     0x00000039 /* Set RX flow hash indir'n table */
>> > > +#define ETHTOOL_SLOOPBACK      0x0000003a /* Enable / Disable Loopback */
>> > [...]
>> >
>> > Where should loopback be done, when enabled?  As near as possible to the
>> > host, so it only covers the DMA engines, or as far away as possible, so
>> > it covers most of the MAC/PHY hardware?
>> >
>> Putting it very close to the HW would stress the maximum soft path and
>> would make it
>> beneficial to more people / developers. I understand that capabilities
>> offered by different
>> NIC vendors vary so it's little difficult to draw the line as to where
>> it  should be done.
>
> Of course, that's why I suggest 'as near/far as possible' rather than
> trying to specify the exact point at which loopback would be enabled.
>
>> So
>> if the theme to "maximize the soft path" is maintained, we can leave
>> it to the individual
>> driver(s) to maximize the value in offering.
>
> I think this should be specified, otherwise measurements on different
> types of NIC will not be comparable.  The ethtool API suffers greatly
> from losse specification and resulting inconsistency between drivers.
> So please add the comment that loopback should be enabled as near to the
> host as possible.
>

This could be seen more as a stress test tool than a performance tool. Also
I think having this feature available for developers is more important than
the place it is done. But I see your point of having more
inconsistencies, so I will
add the comment as guidance for implementation.

--mahesh..
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 6628a50..7523d45 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -678,6 +678,8 @@  struct ethtool_ops {
                                  struct ethtool_rxfh_indir *);
        int     (*set_rxfh_indir)(struct net_device *,
                                  const struct ethtool_rxfh_indir *);
+       int     (*get_loopback)(struct net_device *, u32 *);
+       int     (*set_loopback)(struct net_device *, u32);
 };
 #endif /* __KERNEL__ */

@@ -741,6 +743,8 @@  struct ethtool_ops {
 #define ETHTOOL_GSSET_INFO     0x00000037 /* Get string set info */
 #define ETHTOOL_GRXFHINDIR     0x00000038 /* Get RX flow hash indir'n table */
 #define ETHTOOL_SRXFHINDIR     0x00000039 /* Set RX flow hash indir'n table */
+#define ETHTOOL_SLOOPBACK      0x0000003a /* Enable / Disable Loopback */
+#define ETHTOOL_GLOOPBACK      0x0000003b /* Get Loopback status */

 /* compatibility with older code */
 #define SPARC_ETH_GSET         ETHTOOL_GSET
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 956a9f4..5c87c93 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1434,6 +1434,39 @@  static noinline_for_stack int ethtool_flash_device(struct
        return dev->ethtool_ops->flash_device(dev, &efl);
 }

+static int ethtool_set_loopback(struct net_device *dev, void __user *useraddr)
+{
+       struct ethtool_value edata;
+       const struct ethtool_ops *ops = dev->ethtool_ops;
+
+       if (!ops || !ops->set_loopback)
+               return -EOPNOTSUPP;
+
+       if (copy_from_user(&edata, useraddr, sizeof(edata)))
+               return -EFAULT;
+
+       return ops->set_loopback(dev, edata.data);
+}
+
+static int ethtool_get_loopback(struct net_device *dev, void __user *useraddr)
+{
+       struct ethtool_value edata;
+       const struct ethtool_ops *ops = dev->ethtool_ops;
+       int err;
+
+       if (!ops || !ops->get_loopback)
+               return -EOPNOTSUPP;
+
+       err = ops->get_loopback(dev, &edata.data);
+       if (err)
+               return (err);
+
+       if (copy_to_user(useraddr, &edata, sizeof(edata)))
+               return -EFAULT;
+
+       return 0;
+}
+
 /* The main entry point in this file.  Called from net/core/dev.c */

 int dev_ethtool(struct net *net, struct ifreq *ifr)
@@ -1678,6 +1711,12 @@  int dev_ethtool(struct net *net, struct ifreq *ifr)
        case ETHTOOL_SRXFHINDIR:
                rc = ethtool_set_rxfh_indir(dev, useraddr);
                break;
+       case ETHTOOL_SLOOPBACK:
+               rc = ethtool_set_loopback(dev, useraddr);
+               break;
+       case ETHTOOL_GLOOPBACK:
+               rc = ethtool_get_loopback(dev, useraddr);
+               break;
        default:
                rc = -EOPNOTSUPP;
        }