[PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode.

[PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

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(-)

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;
        }

Re: [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode.

[Simon Horman]

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

Re: [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode.

[Ben Hutchings]

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.

-- 
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.

Re: [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

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.
>

Re: [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode.

[Ben Hutchings]

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.

-- 
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.

Re: [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

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..

[PATCH v2] Net-ethtool : Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

This patch enables ethtool to set the loopback mode on a given
interface. 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) ip -4 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

Signed-off-by: Mahesh Bandewar <maheshb@google.com>

 include/linux/ethtool.h |   15 +++++++++++++++
 net/core/ethtool.c      |   39 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 0 deletions(-)

---
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 6628a50..a7fb1f5 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -616,6 +616,17 @@ void ethtool_ntuple_flush(struct net_device *dev);
  *     Should validate the magic field.  Don't need to check len for zero
  *     or wraparound.  Update len to the amount written.  Returns an error
  *     or zero.
+ *
+ * get_loopback:
+ * set_loopback:
+    These are the driver specific get / set methods to report / enable-
+       disable loopback mode. The idea is to stress test the ingress / egress
+       paths by enabling this mode. There are multiple places this could be
+       done and choice of place will most likely be affected by the device
+       capabilities. So as a guiding principle; select a place to implement
+       loopback mode as close to the host as possible. This would maximize the
+       soft-path length and maintain parity in terms of comparison with differe
+       set of drivers.
  */
 struct ethtool_ops {
        int     (*get_settings)(struct net_device *, struct ethtool_cmd *);
@@ -678,6 +689,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 +754,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;
        }

Re: [PATCH v2] Net-ethtool : Allow ethtool to set interface in loopback mode.

[Ben Hutchings]

On Tue, 2010-11-30 at 15:57 -0800, Mahesh Bandewar wrote:
> This patch enables ethtool to set the loopback mode on a given
> interface. 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.
[...]
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -616,6 +616,17 @@ void ethtool_ntuple_flush(struct net_device *dev);
>   *     Should validate the magic field.  Don't need to check len for zero
>   *     or wraparound.  Update len to the amount written.  Returns an error
>   *     or zero.
> + *
> + * get_loopback:
> + * set_loopback:
> +    These are the driver specific get / set methods to report / enable-
> +       disable loopback mode. The idea is to stress test the ingress / egress
> +       paths by enabling this mode. There are multiple places this could be
> +       done and choice of place will most likely be affected by the device
> +       capabilities. So as a guiding principle; select a place to implement
> +       loopback mode as close to the host as possible. This would maximize the
> +       soft-path length and maintain parity in terms of comparison with differe
> +       set of drivers.
[...]

I know this is nitpicking, but the comment should have asterisks (*)
repeated down the left edge.  Also, a typo: "differe" should be
"different".

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.

Re: [PATCH v3] Net-ethtool : Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

This patch enables ethtool to set the loopback mode on a given
interface. 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) ip -4 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

Signed-off-by: Mahesh Bandewar <maheshb@google.com>

 include/linux/ethtool.h |   15 +++++++++++++++
 net/core/ethtool.c      |   39 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 54 insertions(+), 0 deletions(-)

---

diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 6628a50..8a2cd33 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -616,6 +616,17 @@ void ethtool_ntuple_flush(struct net_device *dev);
  *     Should validate the magic field.  Don't need to check len for zero
  *     or wraparound.  Update len to the amount written.  Returns an error
  *     or zero.
+ *
+ * get_loopback:
+ * set_loopback:
+ *     These are the driver specific get / set methods to report / enable-
+ *     disable loopback mode. The idea is to stress test the ingress/egress
+ *     paths by enabling this mode. There are multiple places this could be
+ *     done and choice of place will most likely be affected by the device
+ *     capabilities. So as a guiding principle; select a place to implement
+ *     loopback mode as close to the host as possible. This would maximize
+ *     the soft-path length and maintain parity in terms of comparison with
+ *     different set of drivers.
  */
 struct ethtool_ops {
        int     (*get_settings)(struct net_device *, struct ethtool_cmd *);
@@ -678,6 +689,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 +754,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

 #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;
        }

Re: [PATCH v3] Net-ethtool : Allow ethtool to set interface in loopback mode.

[Ben Hutchings]

On Wed, 2010-12-01 at 12:14 -0800, Mahesh Bandewar wrote:
> This patch enables ethtool to set the loopback mode on a given
> interface. 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) ip -4 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
> 
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
[...]
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>

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.

Re: [PATCH v3] Net-ethtool : Allow ethtool to set interface in loopback mode.

[David Miller]

From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 01 Dec 2010 20:17:03 +0000

> On Wed, 2010-12-01 at 12:14 -0800, Mahesh Bandewar wrote:
>> This patch enables ethtool to set the loopback mode on a given
>> interface. 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) ip -4 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
>> 
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> [...]
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>

This patch doesn't apply, it has been corrupted by Mahesh's email
client.

Mahesh, please correct this problem and resubmit.

[PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

This patch enables ethtool to set the loopback mode on a given interface.
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) ip -4 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

Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
---
 include/linux/ethtool.h |   16 ++++++++++++++++
 net/core/ethtool.c      |   39 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 6628a50..c036347 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -616,6 +616,18 @@ void ethtool_ntuple_flush(struct net_device *dev);
  *	Should validate the magic field.  Don't need to check len for zero
  *	or wraparound.  Update len to the amount written.  Returns an error
  *	or zero.
+ *
+ * get_loopback:
+ * set_loopback:
+ *	These are the driver specific get / set methods to report / enable-
+ *	disable loopback mode. The idea is to stress test the ingress/egress
+ *	paths by enabling this mode. There are multiple places this could be
+ *	done and choice of place will most likely be affected by the device
+ *	capabilities. So as a guiding principle; select a place to implement 
+ *	loopback mode as close to the host as possible. This would maximize
+ *	the soft-path length and maintain parity in terms of comparison with
+ *	different set of drivers.
+ *
  */
 struct ethtool_ops {
 	int	(*get_settings)(struct net_device *, struct ethtool_cmd *);
@@ -678,6 +690,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 +755,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 net_device *dev,
 	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;
 	}
-- 
1.7.3.1

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Stephen Hemminger]

On Tue,  4 Jan 2011 16:30:01 -0800
Mahesh Bandewar <maheshb@google.com> wrote:

> This patch enables ethtool to set the loopback mode on a given interface.
> 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) ip -4 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
> 
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>

Since this is a boolean it SHOULD go into ethtool_flags rather than
being a high level operation.


-- 

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Ben Hutchings]

On Tue, 2011-01-04 at 16:36 -0800, Stephen Hemminger wrote:
> On Tue,  4 Jan 2011 16:30:01 -0800
> Mahesh Bandewar <maheshb@google.com> wrote:
> 
> > This patch enables ethtool to set the loopback mode on a given interface.
> > 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) ip -4 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
> > 
> > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> > Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
> 
> Since this is a boolean it SHOULD go into ethtool_flags rather than
> being a high level operation.

It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
controlling offload features.

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.

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Stephen Hemminger]

On Wed, 05 Jan 2011 01:21:44 +0000
Ben Hutchings <bhutchings@solarflare.com> wrote:

> On Tue, 2011-01-04 at 16:36 -0800, Stephen Hemminger wrote:
> > On Tue,  4 Jan 2011 16:30:01 -0800
> > Mahesh Bandewar <maheshb@google.com> wrote:
> > 
> > > This patch enables ethtool to set the loopback mode on a given interface.
> > > 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) ip -4 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
> > > 
> > > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> > > Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
> > 
> > Since this is a boolean it SHOULD go into ethtool_flags rather than
> > being a high level operation.
> 
> It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
> controlling offload features.

It just seems the number of hooks keeps growing which takes more space
and increases complexity.

There was some talk about changing GRO/TSO/UFO .. to be bits in FLAGS
but not sure how far along that is.
-- 

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Rick Jones]

>>>Since this is a boolean it SHOULD go into ethtool_flags rather than
>>>being a high level operation.
>>
>>It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
>>controlling offload features.
> 
> 
> It just seems the number of hooks keeps growing which takes more space
> and increases complexity.

Is there any complication/downside to using flags in the (un?)likely event of 
wanting different flavors of loopback in the card?

rick jones

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Stephen Hemminger]

On Tue, 04 Jan 2011 17:34:29 -0800
Rick Jones <rick.jones2@hp.com> wrote:

> >>>Since this is a boolean it SHOULD go into ethtool_flags rather than
> >>>being a high level operation.
> >>
> >>It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
> >>controlling offload features.
> > 
> > 
> > It just seems the number of hooks keeps growing which takes more space
> > and increases complexity.
> 
> Is there any complication/downside to using flags in the (un?)likely event of 
> wanting different flavors of loopback in the card?
> 
> rick jones

Then let is keep it as command and have a parameter to set mode.
There might be drivers that want to loopback in SW, HW, PHY or even switch.

-- 

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Ben Hutchings]

On Tue, 2011-01-04 at 17:34 -0800, Rick Jones wrote:
> >>>Since this is a boolean it SHOULD go into ethtool_flags rather than
> >>>being a high level operation.
> >>
> >>It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
> >>controlling offload features.
> > 
> > 
> > It just seems the number of hooks keeps growing which takes more space
> > and increases complexity.
> 
> Is there any complication/downside to using flags in the (un?)likely event of 
> wanting different flavors of loopback in the card?

You have to define the flags.   And once you start, where would you
stop?  The sfc driver alone recognises 18 host-side and 8 wire-side
loopback modes.

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.

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

On Tue, Jan 4, 2011 at 5:34 PM, Rick Jones <rick.jones2@hp.com> wrote:
>>>> Since this is a boolean it SHOULD go into ethtool_flags rather than
>>>> being a high level operation.
>>>
>>> It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
>>> controlling offload features.
>>
>>
>> It just seems the number of hooks keeps growing which takes more space
>> and increases complexity.
>
> Is there any complication/downside to using flags in the (un?)likely event
> of wanting different flavors of loopback in the card?

The purpose of the patch is to stress / exercise the ingress/egress
path(s). So like Ben had suggested earlier to keep the loopback
implementation as near as possible to the host would streamline /
simplify the implementation & usage.

This is not a new patch and the earlier thread has an answer for this.
It's just that when I re-submitted this patch today, it went in as a
new patch! Here are the reference(s) the old thread -

http://marc.info/?l=linux-netdev&w=3&r=1&s=Allow+ethtool+to+set+interface&q=t

>
> rick jones
>

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

On Tue, Jan 4, 2011 at 5:29 PM, Stephen Hemminger <shemminger@vyatta.com> wrote:
> On Wed, 05 Jan 2011 01:21:44 +0000
> Ben Hutchings <bhutchings@solarflare.com> wrote:
>
>> On Tue, 2011-01-04 at 16:36 -0800, Stephen Hemminger wrote:
>> > On Tue,  4 Jan 2011 16:30:01 -0800
>> > Mahesh Bandewar <maheshb@google.com> wrote:
>> >
>> > > This patch enables ethtool to set the loopback mode on a given interface.
>> > > 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) ip -4 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
>> > >
>> > > Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>> > > Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
>> >
>> > Since this is a boolean it SHOULD go into ethtool_flags rather than
>> > being a high level operation.
>>
>> It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
>> controlling offload features.
>
> It just seems the number of hooks keeps growing which takes more space
> and increases complexity.
>
> There was some talk about changing GRO/TSO/UFO .. to be bits in FLAGS
> but not sure how far along that is.
> --
>

This is not merely getting / setting flags but involves invoking a
method from the driver(s). If done this way; the code in
ethtool_op_set_flags() will have to be special-cased to handle this
flag which (I think) would not be clean.

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Jeff Garzik]

On 01/04/2011 08:21 PM, Ben Hutchings wrote:
> On Tue, 2011-01-04 at 16:36 -0800, Stephen Hemminger wrote:
>> On Tue,  4 Jan 2011 16:30:01 -0800
>> Mahesh Bandewar<maheshb@google.com>  wrote:
>>
>>> This patch enables ethtool to set the loopback mode on a given interface.
>>> 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) ip -4 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
>>>
>>> Signed-off-by: Mahesh Bandewar<maheshb@google.com>
>>> Reviewed-by: Ben Hutchings<bhutchings@solarflare.com>
>>
>> Since this is a boolean it SHOULD go into ethtool_flags rather than
>> being a high level operation.
>
> It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
> controlling offload features.

It doesn't have to be.  As Stephen guessed, [GS]FLAGS are basically 
common flags -- as differentiated from private, 
driver-specific/hardware-specific flags.

	Jeff

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Ben Hutchings]

On Wed, 2011-01-05 at 11:22 -0500, Jeff Garzik wrote:
> On 01/04/2011 08:21 PM, Ben Hutchings wrote:
> > On Tue, 2011-01-04 at 16:36 -0800, Stephen Hemminger wrote:
> >> On Tue,  4 Jan 2011 16:30:01 -0800
> >> Mahesh Bandewar<maheshb@google.com>  wrote:
> >>
> >>> This patch enables ethtool to set the loopback mode on a given interface.
> >>> 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) ip -4 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
> >>>
> >>> Signed-off-by: Mahesh Bandewar<maheshb@google.com>
> >>> Reviewed-by: Ben Hutchings<bhutchings@solarflare.com>
> >>
> >> Since this is a boolean it SHOULD go into ethtool_flags rather than
> >> being a high level operation.
> >
> > It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
> > controlling offload features.
> 
> It doesn't have to be.  As Stephen guessed, [GS]FLAGS are basically 
> common flags -- as differentiated from private, 
> driver-specific/hardware-specific flags.

Well, that would allow the patch to be simplified quite a bit. :-)

Ben.

From: Ben Hutchings <bhutchings@solarflare.com>
Subject: [PATCH net-2.6] ethtool: Define ETH_FLAG_LOOPBACK
Date: Thu, 6 Jan 2011 22:10:55 +0000

Mahesh Bandewar <maheshb@google.com> requested this, writing:

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.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>

--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -309,6 +309,7 @@ struct ethtool_perm_addr {
  * flag differs from the read-only value.
  */
 enum ethtool_flags {
+	ETH_FLAG_LOOPBACK	= (1 << 2),	/* Host-side loopback enabled */
 	ETH_FLAG_TXVLAN		= (1 << 7),	/* TX VLAN offload enabled */
 	ETH_FLAG_RXVLAN		= (1 << 8),	/* RX VLAN offload enabled */
 	ETH_FLAG_LRO		= (1 << 15),	/* LRO is enabled */
---

-- 
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.

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

On Thu, Jan 6, 2011 at 2:13 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Wed, 2011-01-05 at 11:22 -0500, Jeff Garzik wrote:
>> On 01/04/2011 08:21 PM, Ben Hutchings wrote:
>> > On Tue, 2011-01-04 at 16:36 -0800, Stephen Hemminger wrote:
>> >> On Tue,  4 Jan 2011 16:30:01 -0800
>> >> Mahesh Bandewar<maheshb@google.com>  wrote:
>> >>
>> >>> This patch enables ethtool to set the loopback mode on a given interface.
>> >>> 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) ip -4 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
>> >>>
>> >>> Signed-off-by: Mahesh Bandewar<maheshb@google.com>
>> >>> Reviewed-by: Ben Hutchings<bhutchings@solarflare.com>
>> >>
>> >> Since this is a boolean it SHOULD go into ethtool_flags rather than
>> >> being a high level operation.
>> >
>> > It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
>> > controlling offload features.
>>
>> It doesn't have to be.  As Stephen guessed, [GS]FLAGS are basically
>> common flags -- as differentiated from private,
>> driver-specific/hardware-specific flags.
>
> Well, that would allow the patch to be simplified quite a bit. :-)

Ben, Are you suggesting to use ETH_FLAG_LOOPBACK instead of
ETHTOOL_{G|S}LOOPBACK flags?

Thanks,
--mahesh..

>
> Ben.
>
> From: Ben Hutchings <bhutchings@solarflare.com>
> Subject: [PATCH net-2.6] ethtool: Define ETH_FLAG_LOOPBACK
> Date: Thu, 6 Jan 2011 22:10:55 +0000
>
> Mahesh Bandewar <maheshb@google.com> requested this, writing:
>
> 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.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
>
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -309,6 +309,7 @@ struct ethtool_perm_addr {
>  * flag differs from the read-only value.
>  */
>  enum ethtool_flags {
> +       ETH_FLAG_LOOPBACK       = (1 << 2),     /* Host-side loopback enabled */
>        ETH_FLAG_TXVLAN         = (1 << 7),     /* TX VLAN offload enabled */
>        ETH_FLAG_RXVLAN         = (1 << 8),     /* RX VLAN offload enabled */
>        ETH_FLAG_LRO            = (1 << 15),    /* LRO is enabled */
> ---
>
> --
> 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.
>
>

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Ben Hutchings]

On Thu, 2011-01-06 at 16:47 -0800, Mahesh Bandewar wrote:
> On Thu, Jan 6, 2011 at 2:13 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> > On Wed, 2011-01-05 at 11:22 -0500, Jeff Garzik wrote:
> >> On 01/04/2011 08:21 PM, Ben Hutchings wrote:
> >> > On Tue, 2011-01-04 at 16:36 -0800, Stephen Hemminger wrote:
> >> >> On Tue,  4 Jan 2011 16:30:01 -0800
> >> >> Mahesh Bandewar<maheshb@google.com>  wrote:
> >> >>
> >> >>> This patch enables ethtool to set the loopback mode on a given interface.
> >> >>> 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) ip -4 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
> >> >>>
> >> >>> Signed-off-by: Mahesh Bandewar<maheshb@google.com>
> >> >>> Reviewed-by: Ben Hutchings<bhutchings@solarflare.com>
> >> >>
> >> >> Since this is a boolean it SHOULD go into ethtool_flags rather than
> >> >> being a high level operation.
> >> >
> >> > It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
> >> > controlling offload features.
> >>
> >> It doesn't have to be.  As Stephen guessed, [GS]FLAGS are basically
> >> common flags -- as differentiated from private,
> >> driver-specific/hardware-specific flags.
> >
> > Well, that would allow the patch to be simplified quite a bit. :-)
> 
> Ben, Are you suggesting to use ETH_FLAG_LOOPBACK instead of
> ETHTOOL_{G|S}LOOPBACK flags?
[...]

Exactly.

An example implementation (untested):

--- a/drivers/net/sfc/ethtool.c
+++ b/drivers/net/sfc/ethtool.c
@@ -548,11 +548,24 @@ static u32 efx_ethtool_get_rx_csum(struct net_device *net_dev)
 	return efx->rx_checksum_enabled;
 }
 
+static u32 efx_ethtool_get_flags(struct net_device *net_dev)
+{
+	struct efx_nic *efx = netdev_priv(net_dev);
+	u32 flags;
+
+	flags = ethtool_op_get_flags(net_dev);
+	if (efx->loopback_mode != LOOPBACK_NONE)
+		flags |= ETH_FLAG_LOOPBACK;
+	return flags;
+}
+
 static int efx_ethtool_set_flags(struct net_device *net_dev, u32 data)
 {
 	struct efx_nic *efx = netdev_priv(net_dev);
-	u32 supported = (efx->type->offload_features &
-			 (ETH_FLAG_RXHASH | ETH_FLAG_NTUPLE));
+	u32 supported = (ETH_FLAG_LOOPBACK |
+			 (efx->type->offload_features &
+			  (ETH_FLAG_RXHASH | ETH_FLAG_NTUPLE)));
+	enum efx_loopback_mode loopback;
 	int rc;
 
 	rc = ethtool_op_set_flags(net_dev, data, supported);
@@ -562,7 +575,15 @@ static int efx_ethtool_set_flags(struct net_device *net_dev, u32 data)
 	if (!(data & ETH_FLAG_NTUPLE))
 		efx_filter_clear_rx(efx, EFX_FILTER_PRI_MANUAL);
 
-	return 0;
+	loopback = (data & ETH_FLAG_LOOPBACK) ? LOOPBACK_DATA : LOOPBACK_NONE;
+	mutex_lock(&efx->mac_lock);
+	if (efx->loopback_mode != loopback) {
+		efx->loopback_mode = loopback;
+		rc = __efx_reconfigure_port(efx);
+	}
+	mutex_unlock(&efx->mac_lock);
+
+	return rc;
 }
 
 static void efx_ethtool_self_test(struct net_device *net_dev,
@@ -1057,7 +1078,7 @@ const struct ethtool_ops efx_ethtool_ops = {
 	.get_tso		= ethtool_op_get_tso,
 	/* Need to enable/disable TSO-IPv6 too */
 	.set_tso		= efx_ethtool_set_tso,
-	.get_flags		= ethtool_op_get_flags,
+	.get_flags		= efx_ethtool_get_flags,
 	.set_flags		= efx_ethtool_set_flags,
 	.get_sset_count		= efx_ethtool_get_sset_count,
 	.self_test		= efx_ethtool_self_test,
---

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.

Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

On Thu, Jan 6, 2011 at 2:13 PM, Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Wed, 2011-01-05 at 11:22 -0500, Jeff Garzik wrote:
>> On 01/04/2011 08:21 PM, Ben Hutchings wrote:
>> > On Tue, 2011-01-04 at 16:36 -0800, Stephen Hemminger wrote:
>> >> On Tue,  4 Jan 2011 16:30:01 -0800
>> >> Mahesh Bandewar<maheshb@google.com>  wrote:
>> >>
>> >>> This patch enables ethtool to set the loopback mode on a given interface.
>> >>> 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) ip -4 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
>> >>>
>> >>> Signed-off-by: Mahesh Bandewar<maheshb@google.com>
>> >>> Reviewed-by: Ben Hutchings<bhutchings@solarflare.com>
>> >>
>> >> Since this is a boolean it SHOULD go into ethtool_flags rather than
>> >> being a high level operation.
>> >
>> > It could do, but I though ETHTOOL_{G,S}FLAGS were intended for
>> > controlling offload features.
>>
>> It doesn't have to be.  As Stephen guessed, [GS]FLAGS are basically
>> common flags -- as differentiated from private,
>> driver-specific/hardware-specific flags.
>
> Well, that would allow the patch to be simplified quite a bit. :-)
>
> Ben.
>
> From: Ben Hutchings <bhutchings@solarflare.com>
> Subject: [PATCH net-2.6] ethtool: Define ETH_FLAG_LOOPBACK
> Date: Thu, 6 Jan 2011 22:10:55 +0000
>
> Mahesh Bandewar <maheshb@google.com> requested this, writing:
>
> 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.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Acked-by: Mahesh Bandewar <maheshb@google.com>
>
> --- a/include/linux/ethtool.h
> +++ b/include/linux/ethtool.h
> @@ -309,6 +309,7 @@ struct ethtool_perm_addr {
>  * flag differs from the read-only value.
>  */
>  enum ethtool_flags {
> +       ETH_FLAG_LOOPBACK       = (1 << 2),     /* Host-side loopback enabled */
>        ETH_FLAG_TXVLAN         = (1 << 7),     /* TX VLAN offload enabled */
>        ETH_FLAG_RXVLAN         = (1 << 8),     /* RX VLAN offload enabled */
>        ETH_FLAG_LRO            = (1 << 15),    /* LRO is enabled */
> ---
I tried this one with e1000e driver changes. It works but the ethtool
changes are not very clean and I would still prefer the earlier patch
since changes are clean across the board. I'll post ethtool changes
soon.

>
> --
> 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.
>
>

[PATCH v4] net-next-2.6: Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

This patch enables ethtool to set the loopback mode on a given interface.
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) ip -4 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

Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
---
 include/linux/ethtool.h |   16 ++++++++++++++++
 net/core/ethtool.c      |   39 +++++++++++++++++++++++++++++++++++++++
 2 files changed, 55 insertions(+), 0 deletions(-)

diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 1908929..1b12541 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -616,6 +616,18 @@ void ethtool_ntuple_flush(struct net_device *dev);
  *	Should validate the magic field.  Don't need to check len for zero
  *	or wraparound.  Update len to the amount written.  Returns an error
  *	or zero.
+ *
+ * get_loopback:
+ * set_loopback:
+ *	These are the driver specific get / set methods to report / enable-
+ *	disable loopback mode. The idea is to stress test the ingress/egress
+ *	paths by enabling this mode. There are multiple places this could be
+ *	done and choice of place will most likely be affected by the device
+ *	capabilities. So as a guiding principle; select a place to implement 
+ *	loopback mode as close to the host as possible. This would maximize
+ *	the soft-path length and maintain parity in terms of comparison with
+ *	different set of drivers.
+ *
  */
 struct ethtool_ops {
 	int	(*get_settings)(struct net_device *, struct ethtool_cmd *);
@@ -678,6 +690,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__ */
 
@@ -743,6 +757,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 1774178..7a5f11a 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1450,6 +1450,39 @@ static noinline_for_stack int ethtool_flash_device(struct net_device *dev,
 	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)
@@ -1693,6 +1726,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;
 	}
-- 
1.7.3.1

Re: [PATCH v4] net-next-2.6: Allow ethtool to set interface in loopback mode.

[Ben Hutchings]

On Fri, 2011-01-21 at 16:23 -0800, Mahesh Bandewar wrote:
> This patch enables ethtool to set the loopback mode on a given interface.
> 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) ip -4 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
> 
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
[...]

If this version has been revised, you can't claim I reviewed it!
If it's a repost of an earlier version, you should say so.

I thought we agreed that loopback could be treated as a flag, anyway.

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.

Re: [PATCH v4] net-next-2.6: Allow ethtool to set interface in loopback mode.

[Mahesh Bandewar]

On Sat, Jan 22, 2011 at 6:35 PM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Fri, 2011-01-21 at 16:23 -0800, Mahesh Bandewar wrote:
>> This patch enables ethtool to set the loopback mode on a given interface.
>> 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) ip -4 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
>>
>> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
>> Reviewed-by: Ben Hutchings <bhutchings@solarflare.com>
> [...]
>
> If this version has been revised, you can't claim I reviewed it!
> If it's a repost of an earlier version, you should say so.
There were no code changes made since you reviewed last. I made some
formatting changes only and that's why I thought it would be
appropriate to put your name there.
>
> I thought we agreed that loopback could be treated as a flag, anyway.
>
> 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.
>
>

Re: [PATCH v4] net-next-2.6: Allow ethtool to set interface in loopback mode.

[Michał Mirosław]

2011/1/22 Mahesh Bandewar <maheshb@google.com>:
> This patch enables ethtool to set the loopback mode on a given interface.
> 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.
[...]

If this is going to be a flag, then maybe you could look at my ethtool
unification
series
http://marc.info/?l=linux-netdev&m=129573447816532&w=3
and integrate it there?

On the other hand, if this is going to be driver-specific value, then
you should use ethtool_get_value() and ethtool_set_value() instead of
making yet another copy
(linke eg. ETHTOOL_SMSGLVL).

Best Regards,
Michał Mirosław