| Message ID | AANLkTikVaVv4fkLom+NSQgOUzCd2i3mbHkBNQ6PD4d9Y@mail.gmail.com |
|---|---|
| State | Superseded, archived |
| Delegated to: | David Miller |
| Headers | show |
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
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.
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
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.
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
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; }
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