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

[Mahesh Bandewar <maheshb@google.com>]

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