* [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode. @ 2010-11-30 8:00 Mahesh Bandewar 2010-11-30 9:48 ` Simon Horman 2010-11-30 15:01 ` Ben Hutchings 0 siblings, 2 replies; 29+ messages in thread From: Mahesh Bandewar @ 2010-11-30 8:00 UTC (permalink / raw) To: David Miller, linux-netdev 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; } ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode. 2010-11-30 8:00 [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode Mahesh Bandewar @ 2010-11-30 9:48 ` Simon Horman 2010-11-30 15:01 ` Ben Hutchings 1 sibling, 0 replies; 29+ messages in thread From: Simon Horman @ 2010-11-30 9:48 UTC (permalink / raw) To: Mahesh Bandewar; +Cc: David Miller, linux-netdev 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode. 2010-11-30 8:00 [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode Mahesh Bandewar 2010-11-30 9:48 ` Simon Horman @ 2010-11-30 15:01 ` Ben Hutchings 2010-11-30 19:05 ` Mahesh Bandewar 1 sibling, 1 reply; 29+ messages in thread From: Ben Hutchings @ 2010-11-30 15:01 UTC (permalink / raw) To: Mahesh Bandewar; +Cc: David Miller, linux-netdev, laurent chavey 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode. 2010-11-30 15:01 ` Ben Hutchings @ 2010-11-30 19:05 ` Mahesh Bandewar 2010-11-30 19:15 ` Ben Hutchings 0 siblings, 1 reply; 29+ messages in thread From: Mahesh Bandewar @ 2010-11-30 19:05 UTC (permalink / raw) To: Ben Hutchings; +Cc: David Miller, linux-netdev, laurent chavey 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. > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode. 2010-11-30 19:05 ` Mahesh Bandewar @ 2010-11-30 19:15 ` Ben Hutchings 2010-11-30 21:22 ` Mahesh Bandewar 0 siblings, 1 reply; 29+ messages in thread From: Ben Hutchings @ 2010-11-30 19:15 UTC (permalink / raw) To: Mahesh Bandewar; +Cc: David Miller, linux-netdev, laurent chavey 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode. 2010-11-30 19:15 ` Ben Hutchings @ 2010-11-30 21:22 ` Mahesh Bandewar 2010-11-30 23:57 ` [PATCH v2] " Mahesh Bandewar 0 siblings, 1 reply; 29+ messages in thread From: Mahesh Bandewar @ 2010-11-30 21:22 UTC (permalink / raw) To: Ben Hutchings; +Cc: David Miller, linux-netdev, laurent chavey 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.. ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH v2] Net-ethtool : Allow ethtool to set interface in loopback mode. 2010-11-30 21:22 ` Mahesh Bandewar @ 2010-11-30 23:57 ` Mahesh Bandewar 2010-12-01 14:54 ` Ben Hutchings 0 siblings, 1 reply; 29+ messages in thread From: Mahesh Bandewar @ 2010-11-30 23:57 UTC (permalink / raw) To: David Miller, linux-netdev; +Cc: laurent chavey, Ben Hutchings 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; } ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH v2] Net-ethtool : Allow ethtool to set interface in loopback mode. 2010-11-30 23:57 ` [PATCH v2] " Mahesh Bandewar @ 2010-12-01 14:54 ` Ben Hutchings 2010-12-01 20:14 ` [PATCH v3] " Mahesh Bandewar 0 siblings, 1 reply; 29+ messages in thread From: Ben Hutchings @ 2010-12-01 14:54 UTC (permalink / raw) To: Mahesh Bandewar; +Cc: David Miller, linux-netdev, laurent chavey 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] Net-ethtool : Allow ethtool to set interface in loopback mode. 2010-12-01 14:54 ` Ben Hutchings @ 2010-12-01 20:14 ` Mahesh Bandewar 2010-12-01 20:17 ` Ben Hutchings 2011-01-05 0:30 ` [PATCH v2] net: " Mahesh Bandewar 0 siblings, 2 replies; 29+ messages in thread From: Mahesh Bandewar @ 2010-12-01 20:14 UTC (permalink / raw) To: David Miller, linux-netdev, Ben Hutchings; +Cc: laurent chavey 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; } ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH v3] Net-ethtool : Allow ethtool to set interface in loopback mode. 2010-12-01 20:14 ` [PATCH v3] " Mahesh Bandewar @ 2010-12-01 20:17 ` Ben Hutchings 2010-12-10 4:11 ` David Miller 2011-01-05 0:30 ` [PATCH v2] net: " Mahesh Bandewar 1 sibling, 1 reply; 29+ messages in thread From: Ben Hutchings @ 2010-12-01 20:17 UTC (permalink / raw) To: Mahesh Bandewar; +Cc: David Miller, linux-netdev, laurent chavey 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v3] Net-ethtool : Allow ethtool to set interface in loopback mode. 2010-12-01 20:17 ` Ben Hutchings @ 2010-12-10 4:11 ` David Miller 0 siblings, 0 replies; 29+ messages in thread From: David Miller @ 2010-12-10 4:11 UTC (permalink / raw) To: bhutchings; +Cc: maheshb, netdev, chavey 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2010-12-01 20:14 ` [PATCH v3] " Mahesh Bandewar 2010-12-01 20:17 ` Ben Hutchings @ 2011-01-05 0:30 ` Mahesh Bandewar 2011-01-05 0:36 ` Stephen Hemminger 2011-01-22 0:23 ` [PATCH v4] net-next-2.6: " Mahesh Bandewar 1 sibling, 2 replies; 29+ messages in thread From: Mahesh Bandewar @ 2011-01-05 0:30 UTC (permalink / raw) To: David Miller, Ben Hutchings, Laurent Chavey, Tom Herbert Cc: netdev, 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 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-05 0:30 ` [PATCH v2] net: " Mahesh Bandewar @ 2011-01-05 0:36 ` Stephen Hemminger 2011-01-05 1:21 ` Ben Hutchings 2011-01-22 0:23 ` [PATCH v4] net-next-2.6: " Mahesh Bandewar 1 sibling, 1 reply; 29+ messages in thread From: Stephen Hemminger @ 2011-01-05 0:36 UTC (permalink / raw) To: Mahesh Bandewar Cc: David Miller, Ben Hutchings, Laurent Chavey, Tom Herbert, netdev 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. -- ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-05 0:36 ` Stephen Hemminger @ 2011-01-05 1:21 ` Ben Hutchings 2011-01-05 1:29 ` Stephen Hemminger 2011-01-05 16:22 ` Jeff Garzik 0 siblings, 2 replies; 29+ messages in thread From: Ben Hutchings @ 2011-01-05 1:21 UTC (permalink / raw) To: Stephen Hemminger Cc: Mahesh Bandewar, David Miller, Laurent Chavey, Tom Herbert, netdev 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-05 1:21 ` Ben Hutchings @ 2011-01-05 1:29 ` Stephen Hemminger 2011-01-05 1:34 ` Rick Jones 2011-01-05 1:39 ` Mahesh Bandewar 2011-01-05 16:22 ` Jeff Garzik 1 sibling, 2 replies; 29+ messages in thread From: Stephen Hemminger @ 2011-01-05 1:29 UTC (permalink / raw) To: Ben Hutchings Cc: Mahesh Bandewar, David Miller, Laurent Chavey, Tom Herbert, netdev 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. -- ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-05 1:29 ` Stephen Hemminger @ 2011-01-05 1:34 ` Rick Jones 2011-01-05 1:53 ` Stephen Hemminger ` (2 more replies) 2011-01-05 1:39 ` Mahesh Bandewar 1 sibling, 3 replies; 29+ messages in thread From: Rick Jones @ 2011-01-05 1:34 UTC (permalink / raw) To: Stephen Hemminger Cc: Ben Hutchings, Mahesh Bandewar, David Miller, Laurent Chavey, Tom Herbert, netdev >>>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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-05 1:34 ` Rick Jones @ 2011-01-05 1:53 ` Stephen Hemminger 2011-01-05 1:59 ` Ben Hutchings 2011-01-05 2:06 ` Mahesh Bandewar 2 siblings, 0 replies; 29+ messages in thread From: Stephen Hemminger @ 2011-01-05 1:53 UTC (permalink / raw) To: Rick Jones Cc: Ben Hutchings, Mahesh Bandewar, David Miller, Laurent Chavey, Tom Herbert, netdev 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. -- ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-05 1:34 ` Rick Jones 2011-01-05 1:53 ` Stephen Hemminger @ 2011-01-05 1:59 ` Ben Hutchings 2011-01-05 2:06 ` Mahesh Bandewar 2 siblings, 0 replies; 29+ messages in thread From: Ben Hutchings @ 2011-01-05 1:59 UTC (permalink / raw) To: Rick Jones Cc: Stephen Hemminger, Mahesh Bandewar, David Miller, Laurent Chavey, Tom Herbert, netdev 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-05 1:34 ` Rick Jones 2011-01-05 1:53 ` Stephen Hemminger 2011-01-05 1:59 ` Ben Hutchings @ 2011-01-05 2:06 ` Mahesh Bandewar 2 siblings, 0 replies; 29+ messages in thread From: Mahesh Bandewar @ 2011-01-05 2:06 UTC (permalink / raw) To: Rick Jones Cc: Stephen Hemminger, Ben Hutchings, David Miller, Laurent Chavey, Tom Herbert, netdev 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 > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-05 1:29 ` Stephen Hemminger 2011-01-05 1:34 ` Rick Jones @ 2011-01-05 1:39 ` Mahesh Bandewar 1 sibling, 0 replies; 29+ messages in thread From: Mahesh Bandewar @ 2011-01-05 1:39 UTC (permalink / raw) To: Stephen Hemminger Cc: Ben Hutchings, David Miller, Laurent Chavey, Tom Herbert, netdev 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-05 1:21 ` Ben Hutchings 2011-01-05 1:29 ` Stephen Hemminger @ 2011-01-05 16:22 ` Jeff Garzik 2011-01-06 22:13 ` Ben Hutchings 1 sibling, 1 reply; 29+ messages in thread From: Jeff Garzik @ 2011-01-05 16:22 UTC (permalink / raw) To: Ben Hutchings Cc: Stephen Hemminger, Mahesh Bandewar, David Miller, Laurent Chavey, Tom Herbert, netdev 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-05 16:22 ` Jeff Garzik @ 2011-01-06 22:13 ` Ben Hutchings 2011-01-07 0:47 ` Mahesh Bandewar 2011-01-12 19:24 ` Mahesh Bandewar 0 siblings, 2 replies; 29+ messages in thread From: Ben Hutchings @ 2011-01-06 22:13 UTC (permalink / raw) To: Jeff Garzik Cc: Stephen Hemminger, Mahesh Bandewar, David Miller, Laurent Chavey, Tom Herbert, netdev 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-06 22:13 ` Ben Hutchings @ 2011-01-07 0:47 ` Mahesh Bandewar 2011-01-07 1:30 ` Ben Hutchings 2011-01-12 19:24 ` Mahesh Bandewar 1 sibling, 1 reply; 29+ messages in thread From: Mahesh Bandewar @ 2011-01-07 0:47 UTC (permalink / raw) To: Ben Hutchings Cc: Jeff Garzik, Stephen Hemminger, David Miller, Laurent Chavey, Tom Herbert, netdev 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. > > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-07 0:47 ` Mahesh Bandewar @ 2011-01-07 1:30 ` Ben Hutchings 0 siblings, 0 replies; 29+ messages in thread From: Ben Hutchings @ 2011-01-07 1:30 UTC (permalink / raw) To: Mahesh Bandewar Cc: Jeff Garzik, Stephen Hemminger, David Miller, Laurent Chavey, Tom Herbert, netdev 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2] net: Allow ethtool to set interface in loopback mode. 2011-01-06 22:13 ` Ben Hutchings 2011-01-07 0:47 ` Mahesh Bandewar @ 2011-01-12 19:24 ` Mahesh Bandewar 1 sibling, 0 replies; 29+ messages in thread From: Mahesh Bandewar @ 2011-01-12 19:24 UTC (permalink / raw) To: Ben Hutchings Cc: Jeff Garzik, Stephen Hemminger, David Miller, Laurent Chavey, Tom Herbert, netdev 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. > > ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH v4] net-next-2.6: Allow ethtool to set interface in loopback mode. 2011-01-05 0:30 ` [PATCH v2] net: " Mahesh Bandewar 2011-01-05 0:36 ` Stephen Hemminger @ 2011-01-22 0:23 ` Mahesh Bandewar 2011-01-23 2:35 ` Ben Hutchings 2011-01-23 17:32 ` Michał Mirosław 1 sibling, 2 replies; 29+ messages in thread From: Mahesh Bandewar @ 2011-01-22 0:23 UTC (permalink / raw) To: David Miller Cc: Ben Hutchings, Tom Herbert, Laurent Chavey, netdev, 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 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH v4] net-next-2.6: Allow ethtool to set interface in loopback mode. 2011-01-22 0:23 ` [PATCH v4] net-next-2.6: " Mahesh Bandewar @ 2011-01-23 2:35 ` Ben Hutchings 2011-01-23 17:12 ` Mahesh Bandewar 2011-01-23 17:32 ` Michał Mirosław 1 sibling, 1 reply; 29+ messages in thread From: Ben Hutchings @ 2011-01-23 2:35 UTC (permalink / raw) To: Mahesh Bandewar; +Cc: David Miller, Tom Herbert, Laurent Chavey, netdev 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v4] net-next-2.6: Allow ethtool to set interface in loopback mode. 2011-01-23 2:35 ` Ben Hutchings @ 2011-01-23 17:12 ` Mahesh Bandewar 0 siblings, 0 replies; 29+ messages in thread From: Mahesh Bandewar @ 2011-01-23 17:12 UTC (permalink / raw) To: Ben Hutchings; +Cc: David Miller, Tom Herbert, Laurent Chavey, netdev 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. > > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v4] net-next-2.6: Allow ethtool to set interface in loopback mode. 2011-01-22 0:23 ` [PATCH v4] net-next-2.6: " Mahesh Bandewar 2011-01-23 2:35 ` Ben Hutchings @ 2011-01-23 17:32 ` Michał Mirosław 1 sibling, 0 replies; 29+ messages in thread From: Michał Mirosław @ 2011-01-23 17:32 UTC (permalink / raw) To: Mahesh Bandewar Cc: David Miller, Ben Hutchings, Tom Herbert, Laurent Chavey, netdev 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2011-01-23 17:32 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-11-30 8:00 [PATCH] Net-ethtool : Allow ethtool to set interface in loopback mode Mahesh Bandewar 2010-11-30 9:48 ` Simon Horman 2010-11-30 15:01 ` Ben Hutchings 2010-11-30 19:05 ` Mahesh Bandewar 2010-11-30 19:15 ` Ben Hutchings 2010-11-30 21:22 ` Mahesh Bandewar 2010-11-30 23:57 ` [PATCH v2] " Mahesh Bandewar 2010-12-01 14:54 ` Ben Hutchings 2010-12-01 20:14 ` [PATCH v3] " Mahesh Bandewar 2010-12-01 20:17 ` Ben Hutchings 2010-12-10 4:11 ` David Miller 2011-01-05 0:30 ` [PATCH v2] net: " Mahesh Bandewar 2011-01-05 0:36 ` Stephen Hemminger 2011-01-05 1:21 ` Ben Hutchings 2011-01-05 1:29 ` Stephen Hemminger 2011-01-05 1:34 ` Rick Jones 2011-01-05 1:53 ` Stephen Hemminger 2011-01-05 1:59 ` Ben Hutchings 2011-01-05 2:06 ` Mahesh Bandewar 2011-01-05 1:39 ` Mahesh Bandewar 2011-01-05 16:22 ` Jeff Garzik 2011-01-06 22:13 ` Ben Hutchings 2011-01-07 0:47 ` Mahesh Bandewar 2011-01-07 1:30 ` Ben Hutchings 2011-01-12 19:24 ` Mahesh Bandewar 2011-01-22 0:23 ` [PATCH v4] net-next-2.6: " Mahesh Bandewar 2011-01-23 2:35 ` Ben Hutchings 2011-01-23 17:12 ` Mahesh Bandewar 2011-01-23 17:32 ` Michał Mirosław
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.