* Re: [PATCH v2] net/unix: Add secdata to unix_stream msgs
From: Pat Kane @ 2011-03-23 20:23 UTC (permalink / raw)
To: Casey Schaufler
Cc: Eric Paris, David Miller, linux-kernel, netdev, cxzhang, sds,
jmorris, eparis, paul.moore, LSM
In-Reply-To: <4D8A1BB4.4030709@schaufler-ca.com>
>> On Tue, 2011-03-22 at 19:32 -0700, David Miller wrote:
>>> The SELINUX hook implementations even have "_dgram()" in their names.
The LSM hook that I am having problems with, and that the patch fixes
is "secid_to_secctx()" not "socket_getpeersec_dgram()".
Pat
---
^ permalink raw reply
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Randy Dunlap @ 2011-03-23 19:59 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michał Nazarewicz, broonie, lkml, Nicolas Pitre, Greg KH,
David Brownell, Alan Cox, grant.likely, Linux USB list,
andy.green, netdev, Benjamin Herrenschmidt, roger.quadros,
Jaswinder Singh
In-Reply-To: <201103232057.18150.arnd@arndb.de>
On Wed, 23 Mar 2011 20:57:18 +0100 Arnd Bergmann wrote:
> On Wednesday 23 March 2011 20:53:13 Michał Nazarewicz wrote:
> > On Mar 23, 2011 8:36 PM, "Arnd Bergmann" <arnd@arndb.de> wrote:
> > >
> > > On Wednesday 23 March 2011 19:46:50 Greg KH wrote:
> > > > > @@ -97,6 +97,8 @@ struct driver_info {
> > > > >
> > > > > #define FLAG_LINK_INTR 0x0800 /* updates link (carrier) status */
> > > > >
> > > > > +#define FLAG_PTP 0x1000 /* maybe use "usb%d" names */
> > > >
> > > > "PTP"? What does that stand for?
> > >
> > > point-to-point, I'll improve the comment to spell it out when I send the
> > > fixed version.
> >
> > I think P2P could be better.
>
> Yes, good idea.
that's peer-to-peer.
OTOH, I knew that PTP was point-to-point.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Arnd Bergmann @ 2011-03-23 19:57 UTC (permalink / raw)
To: Michał Nazarewicz
Cc: broonie, lkml, Nicolas Pitre, Greg KH, David Brownell, Alan Cox,
grant.likely, Linux USB list, andy.green, netdev,
Benjamin Herrenschmidt, roger.quadros, Jaswinder Singh
In-Reply-To: <AANLkTim7hPfTv3gDYnh+jGxHBg0OvX=r1FKYoHnH7H_o@mail.gmail.com>
On Wednesday 23 March 2011 20:53:13 Michał Nazarewicz wrote:
> On Mar 23, 2011 8:36 PM, "Arnd Bergmann" <arnd@arndb.de> wrote:
> >
> > On Wednesday 23 March 2011 19:46:50 Greg KH wrote:
> > > > @@ -97,6 +97,8 @@ struct driver_info {
> > > >
> > > > #define FLAG_LINK_INTR 0x0800 /* updates link (carrier) status */
> > > >
> > > > +#define FLAG_PTP 0x1000 /* maybe use "usb%d" names */
> > >
> > > "PTP"? What does that stand for?
> >
> > point-to-point, I'll improve the comment to spell it out when I send the
> > fixed version.
>
> I think P2P could be better.
Yes, good idea.
Arnd
^ permalink raw reply
* Re: [PATCH v2] net: Allow no-cache copy from user on transmit
From: Tom Herbert @ 2011-03-23 19:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Michał Mirosław, davem, netdev
In-Reply-To: <20110323122544.032fb543@nehalam>
> Isn't nocache DMA a function of the I/O architecture not a function
> of the device driver? Shouldn't it be handled at PCI level somehow
> with considerations of CPU arch and quirks? Doesn't it make sense for
> non-network traffic as well.
>
> Hate to hold up a good optimization while waiting for a general
> solution, but commiting to an API prematurely would be bad as well.
>
There's an implicit assumption in the patch that if somewhere below
the copyfromuser the data is touched it would be more efficient to
copy through the cache than bypass it. Whether the data is touched is
an attribute of the device and hence the per device control.
Now that I think about it, I don't really know what the actual
performance impact is to bypass cache copy and then touch the data.
I'd be interested to know if anyone has data on that, else I'll try to
contrive some benchmark numbers.
Tom
>
>
> --
>
^ permalink raw reply
* Re: [patch net-2.6] bonding: fix rx_handler locking
From: David Miller @ 2011-03-23 19:45 UTC (permalink / raw)
To: nicolas.2p.debian; +Cc: jpirko, netdev, andy, fubar
In-Reply-To: <4D8A4931.10903@gmail.com>
From: Nicolas de Pesloüan <nicolas.2p.debian@gmail.com>
Date: Wed, 23 Mar 2011 20:25:37 +0100
> Le 22/03/2011 13:38, Jiri Pirko a écrit :
>> This prevents possible race between bond_enslave and bond_handle_frame
>> as reported by Nicolas by moving rx_handler register/unregister.
>> slave->bond is added to hold pointer to master bonding sructure. That
>> way dev->master is no longer used in bond_handler_frame.
>> Also, this removes "BUG: scheduling while atomic" message
>>
>> Reported-by: Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>
>> Signed-off-by: Jiri Pirko<jpirko@redhat.com>
>
> Thanks Jiri, it works.
>
> Tested-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH v2 08/16] mlx4_en: Reporting HW revision in ethtool -i
From: David Miller @ 2011-03-23 19:36 UTC (permalink / raw)
To: yevgenyp; +Cc: bhutchings, netdev, eugenia
In-Reply-To: <953B660C027164448AE903364AC447D20705BE28@mtldag01.mtl.com>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Wed, 23 Mar 2011 15:10:34 +0000
>>
>> This is an abuse of the ethtool_drvinfo::driver field.
>>
>> Your users can use lspci -v, can't they?
>>
> I don't think there is a problem here.
> We have always reported the HW model via Ethtool, we just expanded the information
> we provide.
> Our users prefer to see the information in ethtool.
This doesn't matter, we strive for consistency across drivers rather
than have special cases like this.
Please remove the chip variant information from the ethtool driver
string, it is absolutely not appropriate.
^ permalink raw reply
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Arnd Bergmann @ 2011-03-23 19:35 UTC (permalink / raw)
To: Greg KH
Cc: andy.green, Alan Cox, Benjamin Herrenschmidt, Nicolas Pitre,
Jaswinder Singh, Linux USB list, lkml, broonie, roger.quadros,
grant.likely, netdev, David Brownell
In-Reply-To: <20110323184650.GB21728@kroah.com>
On Wednesday 23 March 2011 19:46:50 Greg KH wrote:
> Looks good to me, but some questions:
>
> > drivers/usb/serial/usb_wwan.c | 2 +-
>
> You don't modify this file in the diff, what caused this to show up in
> the diffstat?
A stale change I had to do to get the kernel to build on my
machine. The original problem seems fixed now. I had removed
this hunk from the patch but forgot to remove it from the diffstat.
> > --- a/include/linux/usb/usbnet.h
> > +++ b/include/linux/usb/usbnet.h
> > @@ -97,6 +97,8 @@ struct driver_info {
> >
> > #define FLAG_LINK_INTR 0x0800 /* updates link (carrier) status */
> >
> > +#define FLAG_PTP 0x1000 /* maybe use "usb%d" names */
>
> "PTP"? What does that stand for?
point-to-point, I'll improve the comment to spell it out when I send the
fixed version.
Arnd
^ permalink raw reply
* Re: [PATCH v2 00/16] mlx4_en: driver updates
From: Ben Hutchings @ 2011-03-23 19:34 UTC (permalink / raw)
To: David Miller; +Cc: yevgenyp, netdev
In-Reply-To: <20110323.122612.229763242.davem@davemloft.net>
On Wed, 2011-03-23 at 12:26 -0700, David Miller wrote:
> From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
> Date: Wed, 23 Mar 2011 10:37:15 +0200
>
> > Hello David,
> >
> > This is the second round for patches originally sent on March 07.
> >
> > Changes from previous round (after getting the feedbacks):
> > 1. Renamed IRQ name for TX rings.
> > 2. Changed error message when failing to map BlueFlame area.
> > 3. Removed drivers/infiniband/hw/mlx4/ parts of steering changes, those need to be applied with Raw QP support.
>
> Series applied to net-2.6, thanks.
Including 08/16 'mlx4_en: Reporting HW revision in ethtool -i'?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
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
* Re: [PATCH v2 08/16] mlx4_en: Reporting HW revision in ethtool -i
From: David Miller @ 2011-03-23 19:34 UTC (permalink / raw)
To: bhutchings; +Cc: yevgenyp, netdev, eugenia
In-Reply-To: <1300889054.26693.527.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 23 Mar 2011 14:04:14 +0000
> On Wed, 2011-03-23 at 10:38 +0200, Yevgeny Petrilin wrote:
>> HW revision is derived from device ID and rev id.
> [...]
>> - sprintf(drvinfo->driver, DRV_NAME " (%s)", mdev->dev->board_id);
>> + switch (mdev->dev->rev_id) {
>> + case 0xa0:
>> + if (dev->dev_id >= MLX4_EN_CX3_LOW_ID && dev->dev_id <= MLX4_EN_CX3_HIGH_ID)
>> + sprintf(drvinfo->driver, DRV_NAME " (%s_CX-3)", mdev->dev->board_id);
>> + else
>> + sprintf(drvinfo->driver, DRV_NAME " (%s_CX)", mdev->dev->board_id);
>> + break;
>> + case 0xb0:
>> + sprintf(drvinfo->driver, DRV_NAME " (%s_CX-2)", mdev->dev->board_id);
>> + break;
>> + default:
>> + sprintf(drvinfo->driver, DRV_NAME " (%s)", mdev->dev->board_id);
>> + break;
> [...]
>
> This is an abuse of the ethtool_drvinfo::driver field.
>
> Your users can use lspci -v, can't they?
Agreed, mlx4 folks please send me a follow-up patch that removes this
conditional string.
The driver string is only meant to identify the software, not the
hardware variant.
^ permalink raw reply
* Re: [PATCH] myri10ge: fix rmmod crash
From: David Miller @ 2011-03-23 19:31 UTC (permalink / raw)
To: gallatin; +Cc: sgruszka, netdev, brice, stable
In-Reply-To: <4D89F111.7030506@myri.com>
From: Andrew Gallatin <gallatin@myri.com>
Date: Wed, 23 Mar 2011 09:09:37 -0400
> On 03/23/11 08:44, Stanislaw Gruszka wrote:
>> Rmmod myri10ge crash at free_netdev() -> netif_napi_del(), because
>> napi
>> structures are already deallocated. To fix call netif_napi_del()
>> before
>> kfree() at myri10ge_free_slices().
>
> I apologize; I made a similar fix myself to our tree last fall simply
> forgot to post it to netdev... I'm terribly sorry for the time
> you wasted chasing this. At any rate...
>
> Acked by: Andrew Gallatin <gallatin@myri.com>
Patch applied, thanks everyone.
^ permalink raw reply
* Re: bridge not routing packets via source bridgeport
From: David Miller @ 2011-03-23 19:27 UTC (permalink / raw)
To: sebastian.bronner; +Cc: netdev, daniel.kraft
In-Reply-To: <4D89C797.2010403@d9t.de>
From: "Sebastian J. Bronner" <sebastian.bronner@d9t.de>
Date: Wed, 23 Mar 2011 11:12:39 +0100
> I have submitted this bug on the kernel bugtracker. Further discussion
> should probably take place there:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=31722
That's never the right thing to do.
Core developers, including myself, absolutely do not follow the
bugzilla entries. We follow the discussion that occurs here on
the mailing lists only.
So if you want the core networking folks to follow this, keep
the discussion here on the lists.
^ permalink raw reply
* Re: [PATCH v2] net: Allow no-cache copy from user on transmit
From: Stephen Hemminger @ 2011-03-23 19:25 UTC (permalink / raw)
To: Michał Mirosław; +Cc: Tom Herbert, davem, netdev
In-Reply-To: <AANLkTi=Tg4jW7hZZ43E71GNi+d8JWMJQcv3ExZA6zJQW@mail.gmail.com>
On Wed, 23 Mar 2011 19:42:20 +0100
Michał Mirosław <mirqus@gmail.com> wrote:
> 2011/3/23 Tom Herbert <therbert@google.com>:
> > This patch uses __copy_from_user_nocache (from skb_copy_to_page)
> > on transmit to bypass data cache for a performance improvement.
> > This functionality is configurable per device using ethtool, the
> > device must also be doing TX csum offload to enable. It seems
> > reasonable to set this when the netdevice does not copy or
> > otherwise touch the data.
> >
> > This patch was tested using 200 instances of netperf TCP_RR with
> > 1400 byte request and one byte reply. Platform is 16 core AMD x86.
> >
> > No-cache copy disabled:
> > 672703 tps, 97.13% utilization
> > 50/90/99% latency:244.31 484.205 1028.41
> >
> > No-cache copy enabled:
> > 702113 tps, 96.16% utilization,
> > 50/90/99% latency 238.56 467.56 956.955
> >
> > Using 14000 byte request and response sizes demonstrate the
> > effects more dramatically:
> >
> > No-cache copy disabled:
> > 79571 tps, 34.34 %utlization
> > 50/90/95% latency 1584.46 2319.59 5001.76
> >
> > No-cache copy enabled:
> > 83856 tps, 34.81% utilization
> > 50/90/95% latency 2508.42 2622.62 2735.88
> >
> > Note especially the effect on tail latency (95th percentile).
> >
> > This seems to provide a nice performance improvement and is
> > consistent in the tests I ran. Presumably, this would provide
> > the greatest benfits in the presence of an application workload
> > stressing the cache and a lot of transmit data happening. I don't
> > yet see a downside to using this.
> >
> > Signed-off-by: Tom Herbert <therbert@google.com>
> > ---
> > include/linux/netdevice.h | 10 ++++++++--
> > include/net/sock.h | 5 +++++
> > net/core/dev.c | 2 +-
> > net/core/ethtool.c | 2 +-
> > 4 files changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> > index 5eeb2cd..52d444f 100644
> > --- a/include/linux/netdevice.h
> > +++ b/include/linux/netdevice.h
> > @@ -1066,6 +1066,7 @@ struct net_device {
> > #define NETIF_F_NTUPLE (1 << 27) /* N-tuple filters supported */
> > #define NETIF_F_RXHASH (1 << 28) /* Receive hashing offload */
> > #define NETIF_F_RXCSUM (1 << 29) /* Receive checksumming offload */
> > +#define NETIF_F_NOCACHE_COPY (1 << 30) /* Use no-cache copyfromuser */
> >
> > /* Segmentation offload features */
> > #define NETIF_F_GSO_SHIFT 16
> > @@ -1081,7 +1082,7 @@ struct net_device {
> > /* = all defined minus driver/device-class-related */
> > #define NETIF_F_NEVER_CHANGE (NETIF_F_HIGHDMA | NETIF_F_VLAN_CHALLENGED | \
> > NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
> > -#define NETIF_F_ETHTOOL_BITS (0x3f3fffff & ~NETIF_F_NEVER_CHANGE)
> > +#define NETIF_F_ETHTOOL_BITS (0x7f3fffff & ~NETIF_F_NEVER_CHANGE)
> >
> > /* List of features with software fallbacks. */
> > #define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN | \
> > @@ -1108,7 +1109,12 @@ struct net_device {
> > NETIF_F_FRAGLIST)
> >
> > /* changeable features with no special hardware requirements */
> > -#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO)
> > +#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO | \
> > + NETIF_F_NOCACHE_COPY)
> > +
> > + /* soft features automatically enabled */
> > +#define NETIF_F_SOFT_FEAT_ENAB (NETIF_F_GSO | NETIF_F_GRO)
> > +
> >
> > /* Interface index. Unique device identifier */
> > int ifindex;
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index da0534d..74ce586 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -1401,6 +1401,11 @@ static inline int skb_copy_to_page(struct sock *sk, char __user *from,
> > if (err)
> > return err;
> > skb->csum = csum_block_add(skb->csum, csum, skb->len);
> > + } else if (sk->sk_route_caps & NETIF_F_NOCACHE_COPY) {
> > + if (!access_ok(VERIFY_READ, from, copy) ||
> > + __copy_from_user_nocache(page_address(page) + off,
> > + from, copy))
> > + return -EFAULT;
> > } else if (copy_from_user(page_address(page) + off, from, copy))
> > return -EFAULT;
> >
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 0b88eba..c3ed95e 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -5435,7 +5435,7 @@ int register_netdevice(struct net_device *dev)
> > * software offloads (GSO and GRO).
> > */
> > dev->hw_features |= NETIF_F_SOFT_FEATURES;
> > - dev->features |= NETIF_F_SOFT_FEATURES;
> > + dev->features |= NETIF_F_SOFT_FEAT_ENAB;
> > dev->wanted_features = dev->features & dev->hw_features;
> >
> > /* Avoid warning from netdev_fix_features() for GSO without SG */
> > diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> > index c1a71bb..40b6fe0 100644
> > --- a/net/core/ethtool.c
> > +++ b/net/core/ethtool.c
> > @@ -344,7 +344,7 @@ static const char netdev_features_strings[ETHTOOL_DEV_FEATURE_WORDS * 32][ETH_GS
> > /* NETIF_F_NTUPLE */ "rx-ntuple-filter",
> > /* NETIF_F_RXHASH */ "rx-hashing",
> > /* NETIF_F_RXCSUM */ "rx-checksum",
> > - "",
> > + /* NETIF_F_NOCACHE_COPY */ "tx-nocache-copy"
> > "",
> > };
>
> I would rather see it enabled by default, including "hacks" in
> register_netdev() like for GSO. Otherwise not much people will test
> this. There should also be constraints for it in
> netdev_fix_features().
>
> BTW, what happens if this is used on e.g. bridge device or veth and
> later packet ends up going to device which needs to do checksumming in
> software?
The configuration via device and ethtool seems problematic for general use
in a distro. Nice for testing, but not really matching the architecture
issues.
Isn't nocache DMA a function of the I/O architecture not a function
of the device driver? Shouldn't it be handled at PCI level somehow
with considerations of CPU arch and quirks? Doesn't it make sense for
non-network traffic as well.
Hate to hold up a good optimization while waiting for a general
solution, but commiting to an API prematurely would be bad as well.
--
^ permalink raw reply
* Re: [patch net-2.6] bonding: fix rx_handler locking
From: Nicolas de Pesloüan @ 2011-03-23 19:25 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, andy, fubar
In-Reply-To: <1300797492-16128-1-git-send-email-jpirko@redhat.com>
Le 22/03/2011 13:38, Jiri Pirko a écrit :
> This prevents possible race between bond_enslave and bond_handle_frame
> as reported by Nicolas by moving rx_handler register/unregister.
> slave->bond is added to hold pointer to master bonding sructure. That
> way dev->master is no longer used in bond_handler_frame.
> Also, this removes "BUG: scheduling while atomic" message
>
> Reported-by: Nicolas de Pesloüan<nicolas.2p.debian@gmail.com>
> Signed-off-by: Jiri Pirko<jpirko@redhat.com>
Thanks Jiri, it works.
Tested-by: Nicolas de Pesloüan <nicolas.2p.debian@free.fr>
Regarding the code review, can you explain the reasons why you apparently duplicated the fields
related to the slave/master relationship?
Do you plan to totally remove dev->master usage in bonding in a follow-up patch?
Nicolas.
^ permalink raw reply
* Re: [PATCH v2 00/16] mlx4_en: driver updates
From: David Miller @ 2011-03-23 19:26 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <4D89B13B.2010404@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Wed, 23 Mar 2011 10:37:15 +0200
> Hello David,
>
> This is the second round for patches originally sent on March 07.
>
> Changes from previous round (after getting the feedbacks):
> 1. Renamed IRQ name for TX rings.
> 2. Changed error message when failing to map BlueFlame area.
> 3. Removed drivers/infiniband/hw/mlx4/ parts of steering changes, those need to be applied with Raw QP support.
Series applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] via-velocity: fix the WOL bug on 1000M full duplex forced mode.
From: David Miller @ 2011-03-23 19:25 UTC (permalink / raw)
To: davidlv.linux; +Cc: netdev, DavidLv
In-Reply-To: <AANLkTikoVgwu1SQ_fpTLS3coqOWbMy__9Y9eANYYmkWo@mail.gmail.com>
From: David Lv <davidlv.linux@gmail.com>
Date: Wed, 23 Mar 2011 18:07:54 +0800
> Hi, David. I haven't found out this patch code in the mainline of 2.6.38.
> Could you help me check it?
It's there in Linus's tree, it did not make it into 2.6.38:
commit 2ffa007eaa01cf5fedd6a71f7d43854339a831ee
Author: françois romieu <romieu@fr.zoreil.com>
Date: Thu Jan 20 04:59:33 2011 +0000
via-velocity: fix the WOL bug on 1000M full duplex forced mode.
The VIA velocity card can't be waken up by WOL tool on 1000M full
duplex forced mode. This patch fixes the bug.
Signed-off-by: David Lv <DavidLv@viatech.com.cn>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: 2.6.39-rc: WARNING: at __ip_select_ident+0xd3/0xf0()
From: David Miller @ 2011-03-23 19:18 UTC (permalink / raw)
To: eric.dumazet; +Cc: a.beregalov, linux-kernel, netdev
In-Reply-To: <1300873779.3063.39.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 23 Mar 2011 10:49:39 +0100
> [PATCH] ipv4: fix ip_rt_update_pmtu()
>
> commit 2c8cec5c10bc (Cache learned PMTU information in inetpeer) added
> an extra inet_putpeer() call in ip_rt_update_pmtu().
>
> This results in various problems, since we can free one inetpeer, while
> it is still in use.
>
> Ref: http://www.spinics.net/lists/netdev/msg159121.html
>
> Reported-by: Alexander Beregalov <a.beregalov@gmail.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v2] net: Allow no-cache copy from user on transmit
From: Rick Jones @ 2011-03-23 18:51 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1103231003120.16608@pokey.mtv.corp.google.com>
On Wed, 2011-03-23 at 10:10 -0700, Tom Herbert wrote:
> This patch uses __copy_from_user_nocache (from skb_copy_to_page)
> on transmit to bypass data cache for a performance improvement.
> This functionality is configurable per device using ethtool, the
> device must also be doing TX csum offload to enable. It seems
> reasonable to set this when the netdevice does not copy or
> otherwise touch the data.
>
> This patch was tested using 200 instances of netperf TCP_RR with
> 1400 byte request and one byte reply. Platform is 16 core AMD x86.
>
> No-cache copy disabled:
> 672703 tps, 97.13% utilization
> 50/90/99% latency:244.31 484.205 1028.41
>
> No-cache copy enabled:
> 702113 tps, 96.16% utilization,
> 50/90/99% latency 238.56 467.56 956.955
>
> Using 14000 byte request and response sizes demonstrate the
> effects more dramatically:
>
> No-cache copy disabled:
> 79571 tps, 34.34 %utlization
> 50/90/95% latency 1584.46 2319.59 5001.76
>
> No-cache copy enabled:
> 83856 tps, 34.81% utilization
> 50/90/95% latency 2508.42 2622.62 2735.88
>
> Note especially the effect on tail latency (95th percentile).
>
> This seems to provide a nice performance improvement and is
> consistent in the tests I ran. Presumably, this would provide
> the greatest benfits in the presence of an application workload
> stressing the cache and a lot of transmit data happening. I don't
> yet see a downside to using this.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Having raised the question about tying it to CKO and seeing it addressed
to my satisfaction I'll go ahead and:
Acked-by: Rick Jones <rick.jones2@hp.com>
rick jones
^ permalink raw reply
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Greg KH @ 2011-03-23 18:46 UTC (permalink / raw)
To: Arnd Bergmann
Cc: andy.green, Alan Cox, Benjamin Herrenschmidt, Nicolas Pitre,
Jaswinder Singh, Linux USB list, lkml, broonie, roger.quadros,
grant.likely, netdev, David Brownell
In-Reply-To: <201103231756.39849.arnd@arndb.de>
On Wed, Mar 23, 2011 at 05:56:39PM +0100, Arnd Bergmann wrote:
> The documentation for the USB ethernet devices suggests that
> only some devices are supposed to use usb0 as the network interface
> name instead of eth0. The logic used there, and documented in
> Kconfig for CDC is that eth0 will be used when the mac address
> is a globally assigned one, but usb0 is used for the locally
> managed range that is typically used on point-to-point links.
>
> Unfortunately, this has caused a lot of pain on the smsc95xx
> device that is used on the popular pandaboard without an
> EEPROM to store the MAC address, which causes the driver to
> call random_ether_address().
>
> Obviously, there should be a proper MAC addressed assigned to
> the device, and discussions are ongoing about how to solve
> this, but this patch at least makes sure that the default
> interface naming gets a little saner and matches what the
> user can expect based on the documentation, including for
> new devices.
>
> The approach taken here is to flag whether a device might be a
> point-to-point link with the new FLAG_PTP setting in the usbnet
> driver_info. A driver can set both FLAG_PTP and FLAG_ETHER if
> it is not sure (e.g. cdc_ether), or just one of the two.
> The usbnet framework only looks at the MAC address for device
> naming if both flags are set, otherwise it trusts the flag.
>
> Signed-off-by: Arnd Bergmann <arnd.bergmann@linaro.org>
> Cc: Andy Green <andy.green@linaro.org>
Looks good to me, but some questions:
> drivers/usb/serial/usb_wwan.c | 2 +-
You don't modify this file in the diff, what caused this to show up in
the diffstat?
> --- a/include/linux/usb/usbnet.h
> +++ b/include/linux/usb/usbnet.h
> @@ -97,6 +97,8 @@ struct driver_info {
>
> #define FLAG_LINK_INTR 0x0800 /* updates link (carrier) status */
>
> +#define FLAG_PTP 0x1000 /* maybe use "usb%d" names */
"PTP"? What does that stand for?
curious,
greg k-h
^ permalink raw reply
* Re: [PATCH v2] net: Allow no-cache copy from user on transmit
From: Michał Mirosław @ 2011-03-23 18:42 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1103231003120.16608@pokey.mtv.corp.google.com>
2011/3/23 Tom Herbert <therbert@google.com>:
> This patch uses __copy_from_user_nocache (from skb_copy_to_page)
> on transmit to bypass data cache for a performance improvement.
> This functionality is configurable per device using ethtool, the
> device must also be doing TX csum offload to enable. It seems
> reasonable to set this when the netdevice does not copy or
> otherwise touch the data.
>
> This patch was tested using 200 instances of netperf TCP_RR with
> 1400 byte request and one byte reply. Platform is 16 core AMD x86.
>
> No-cache copy disabled:
> 672703 tps, 97.13% utilization
> 50/90/99% latency:244.31 484.205 1028.41
>
> No-cache copy enabled:
> 702113 tps, 96.16% utilization,
> 50/90/99% latency 238.56 467.56 956.955
>
> Using 14000 byte request and response sizes demonstrate the
> effects more dramatically:
>
> No-cache copy disabled:
> 79571 tps, 34.34 %utlization
> 50/90/95% latency 1584.46 2319.59 5001.76
>
> No-cache copy enabled:
> 83856 tps, 34.81% utilization
> 50/90/95% latency 2508.42 2622.62 2735.88
>
> Note especially the effect on tail latency (95th percentile).
>
> This seems to provide a nice performance improvement and is
> consistent in the tests I ran. Presumably, this would provide
> the greatest benfits in the presence of an application workload
> stressing the cache and a lot of transmit data happening. I don't
> yet see a downside to using this.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/netdevice.h | 10 ++++++++--
> include/net/sock.h | 5 +++++
> net/core/dev.c | 2 +-
> net/core/ethtool.c | 2 +-
> 4 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 5eeb2cd..52d444f 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -1066,6 +1066,7 @@ struct net_device {
> #define NETIF_F_NTUPLE (1 << 27) /* N-tuple filters supported */
> #define NETIF_F_RXHASH (1 << 28) /* Receive hashing offload */
> #define NETIF_F_RXCSUM (1 << 29) /* Receive checksumming offload */
> +#define NETIF_F_NOCACHE_COPY (1 << 30) /* Use no-cache copyfromuser */
>
> /* Segmentation offload features */
> #define NETIF_F_GSO_SHIFT 16
> @@ -1081,7 +1082,7 @@ struct net_device {
> /* = all defined minus driver/device-class-related */
> #define NETIF_F_NEVER_CHANGE (NETIF_F_HIGHDMA | NETIF_F_VLAN_CHALLENGED | \
> NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
> -#define NETIF_F_ETHTOOL_BITS (0x3f3fffff & ~NETIF_F_NEVER_CHANGE)
> +#define NETIF_F_ETHTOOL_BITS (0x7f3fffff & ~NETIF_F_NEVER_CHANGE)
>
> /* List of features with software fallbacks. */
> #define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN | \
> @@ -1108,7 +1109,12 @@ struct net_device {
> NETIF_F_FRAGLIST)
>
> /* changeable features with no special hardware requirements */
> -#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO)
> +#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO | \
> + NETIF_F_NOCACHE_COPY)
> +
> + /* soft features automatically enabled */
> +#define NETIF_F_SOFT_FEAT_ENAB (NETIF_F_GSO | NETIF_F_GRO)
> +
>
> /* Interface index. Unique device identifier */
> int ifindex;
> diff --git a/include/net/sock.h b/include/net/sock.h
> index da0534d..74ce586 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1401,6 +1401,11 @@ static inline int skb_copy_to_page(struct sock *sk, char __user *from,
> if (err)
> return err;
> skb->csum = csum_block_add(skb->csum, csum, skb->len);
> + } else if (sk->sk_route_caps & NETIF_F_NOCACHE_COPY) {
> + if (!access_ok(VERIFY_READ, from, copy) ||
> + __copy_from_user_nocache(page_address(page) + off,
> + from, copy))
> + return -EFAULT;
> } else if (copy_from_user(page_address(page) + off, from, copy))
> return -EFAULT;
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 0b88eba..c3ed95e 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5435,7 +5435,7 @@ int register_netdevice(struct net_device *dev)
> * software offloads (GSO and GRO).
> */
> dev->hw_features |= NETIF_F_SOFT_FEATURES;
> - dev->features |= NETIF_F_SOFT_FEATURES;
> + dev->features |= NETIF_F_SOFT_FEAT_ENAB;
> dev->wanted_features = dev->features & dev->hw_features;
>
> /* Avoid warning from netdev_fix_features() for GSO without SG */
> diff --git a/net/core/ethtool.c b/net/core/ethtool.c
> index c1a71bb..40b6fe0 100644
> --- a/net/core/ethtool.c
> +++ b/net/core/ethtool.c
> @@ -344,7 +344,7 @@ static const char netdev_features_strings[ETHTOOL_DEV_FEATURE_WORDS * 32][ETH_GS
> /* NETIF_F_NTUPLE */ "rx-ntuple-filter",
> /* NETIF_F_RXHASH */ "rx-hashing",
> /* NETIF_F_RXCSUM */ "rx-checksum",
> - "",
> + /* NETIF_F_NOCACHE_COPY */ "tx-nocache-copy"
> "",
> };
I would rather see it enabled by default, including "hacks" in
register_netdev() like for GSO. Otherwise not much people will test
this. There should also be constraints for it in
netdev_fix_features().
BTW, what happens if this is used on e.g. bridge device or veth and
later packet ends up going to device which needs to do checksumming in
software?
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: David Anders @ 2011-03-23 17:54 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Greg KH, andy.green@linaro.org, Alan Cox, Benjamin Herrenschmidt,
Nicolas Pitre, Jaswinder Singh, Linux USB list, lkml,
broonie@opensource.wolfsonmicro.com, roger.quadros@nokia.com,
grant.likely@secretlab.ca, netdev@vger.kernel.org, David Brownell
In-Reply-To: <201103231813.41776.arnd@arndb.de>
On 03/23/2011 12:13 PM, Arnd Bergmann wrote:
> On Wednesday 23 March 2011, Arnd Bergmann wrote:
>
>> --- a/drivers/net/usb/smsc75xx.c
>> +++ b/drivers/net/usb/smsc75xx.c
>> @@ -1244,7 +1244,7 @@ static const struct driver_info smsc75xx_info = {
>> .rx_fixup = smsc75xx_rx_fixup,
>> .tx_fixup = smsc75xx_tx_fixup,
>> .status = smsc75xx_status,
>> - .flags = FLAG_ETHER | FLAG_SEND_ZLP,
>> + .flags = FLAG_ETHER | FLAG_SEND_ZLP | FLAG_REALLY_ETHER,
>> };
>>
>> static const struct usb_device_id products[] = {
>> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
>> index bc86f4b..c98d3a7 100644
>> --- a/drivers/net/usb/smsc95xx.c
>> +++ b/drivers/net/usb/smsc95xx.c
>> @@ -1231,7 +1231,7 @@ static const struct driver_info smsc95xx_info = {
>> .rx_fixup = smsc95xx_rx_fixup,
>> .tx_fixup = smsc95xx_tx_fixup,
>> .status = smsc95xx_status,
>> - .flags = FLAG_ETHER | FLAG_SEND_ZLP,
>> + .flags = FLAG_ETHER | FLAG_SEND_ZLP | FLAG_REALLY_ETHER,
>> };
>>
>>
> These two hunks are from an earlier version of the patch and should not
> be there, they break compilation. I'll wait for more comments and
> then send a fixed version.
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
tested with 2.6.38 using omap2plus_defconfig with EHCI and smsc95xx
turned on minus the FLAG_REALLY_ETHER. appears to work properly, assigns
as eth0.
i ran some basic net tests with no issues.
Dave Anders
^ permalink raw reply
* Re: [PATCH ethtool] ethtool: Report driver features described in struct ethtool_drvinfo
From: Ben Hutchings @ 2011-03-23 17:18 UTC (permalink / raw)
To: Ajit.Khaparde; +Cc: netdev
In-Reply-To: <1300488277.2589.50.camel@bwh-desktop>
On Fri, 2011-03-18 at 22:44 +0000, Ben Hutchings wrote:
> On Fri, 2011-03-18 at 15:07 -0700, Ajit.Khaparde@Emulex.Com wrote:
> > ________________________________________
> > From: Ben Hutchings [bhutchings@solarflare.com]
> > Sent: Friday, March 18, 2011 5:00 PM
> > To: Khaparde, Ajit
> > Cc: netdev@vger.kernel.org
> > Subject: RE: [RFC] ethtool: Display reg dump length via get driver info.
> >
> > > On Fri, 2011-03-18 at 14:52 -0700, Ajit.Khaparde@Emulex.Com wrote:
> > >> ______________________________________
> > >> From: Ben Hutchings [bhutchings@solarflare.com]
> > >> Sent: Friday, March 18, 2011 4:32 PM
> > >> To: Khaparde, Ajit
> > >> Cc: netdev@vger.kernel.org
> > >> Subject: Re: [RFC] ethtool: Display reg dump length via get driver info.
> > >>
> > >> On Fri, 2011-03-18 at 16:06 -0500, Ajit Khaparde wrote:
> > >> >> Devices like BE store Reg Dump Data in the hardware.
> > >>
> > > >> Where else would it be?
> > >>
> > >> Well yes. That's true.
> > >>
> > >> >> This change will allow to just peek into the hardware
> > >> >> to see if any data is available for a dump and analysis,
> > >> >> without actually dumping the register data.
> > >> > [...]
> > >>
> > >> > This is wrong. ethtool_ops::get_regs_len really should return a
> > >> > constant, otherwise ethtool (and the kernel) cannot allocate a buffer of
> > >> > the right size. If the size of a dump really does vary then make it
> > >> > return the maximum possible size for the device.
> > >>
> > >> Yes, it is a constant size. And will always be the max size possible.
> > >> I just want to see if I can get the length, without really making the ethtoool -d call.
> > >> Because that will trigger the dump too.
> > >> At that moment, I may not be interested in the data itself.
> >
> > > OK, so what you're really interested in is 'does this version of the
> > > driver support register dump'?
> >
> > Yes. I did not want to add another option in ethtool to get this info out.
>
> So, how about this?
[...]
I've applied this change.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
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
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Arnd Bergmann @ 2011-03-23 17:13 UTC (permalink / raw)
To: Greg KH
Cc: andy.green, Alan Cox, Benjamin Herrenschmidt, Nicolas Pitre,
Jaswinder Singh, Linux USB list, lkml, broonie, roger.quadros,
grant.likely, netdev, David Brownell
In-Reply-To: <201103231756.39849.arnd@arndb.de>
On Wednesday 23 March 2011, Arnd Bergmann wrote:
> --- a/drivers/net/usb/smsc75xx.c
> +++ b/drivers/net/usb/smsc75xx.c
> @@ -1244,7 +1244,7 @@ static const struct driver_info smsc75xx_info = {
> .rx_fixup = smsc75xx_rx_fixup,
> .tx_fixup = smsc75xx_tx_fixup,
> .status = smsc75xx_status,
> - .flags = FLAG_ETHER | FLAG_SEND_ZLP,
> + .flags = FLAG_ETHER | FLAG_SEND_ZLP | FLAG_REALLY_ETHER,
> };
>
> static const struct usb_device_id products[] = {
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> index bc86f4b..c98d3a7 100644
> --- a/drivers/net/usb/smsc95xx.c
> +++ b/drivers/net/usb/smsc95xx.c
> @@ -1231,7 +1231,7 @@ static const struct driver_info smsc95xx_info = {
> .rx_fixup = smsc95xx_rx_fixup,
> .tx_fixup = smsc95xx_tx_fixup,
> .status = smsc95xx_status,
> - .flags = FLAG_ETHER | FLAG_SEND_ZLP,
> + .flags = FLAG_ETHER | FLAG_SEND_ZLP | FLAG_REALLY_ETHER,
> };
>
These two hunks are from an earlier version of the patch and should not
be there, they break compilation. I'll wait for more comments and
then send a fixed version.
Arnd
^ permalink raw reply
* Re: [RFC] usbnet: use eth%d name for known ethernet devices
From: Arnd Bergmann @ 2011-03-23 17:11 UTC (permalink / raw)
To: andy.green
Cc: Greg KH, Alan Cox, Benjamin Herrenschmidt, Nicolas Pitre,
Jaswinder Singh, Linux USB list, lkml, broonie, roger.quadros,
grant.likely, netdev, David Brownell
In-Reply-To: <4D8A2830.6020706@linaro.org>
On Wednesday 23 March 2011, Andy Green wrote:
> > diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> > index bc86f4b..c98d3a7 100644
> > --- a/drivers/net/usb/smsc95xx.c
> > +++ b/drivers/net/usb/smsc95xx.c
> > @@ -1231,7 +1231,7 @@ static const struct driver_info smsc95xx_info = {
>
> > - .flags = FLAG_ETHER | FLAG_SEND_ZLP,
> > + .flags = FLAG_ETHER | FLAG_SEND_ZLP | FLAG_REALLY_ETHER,
>
> > if ((dev->driver_info->flags& FLAG_ETHER) != 0&&
> > + ((dev->driver_info->flags& FLAG_PTP) == 0 ||
> > + (net->dev_addr [0]& 0x02) == 0))
> > strcpy (net->name, "eth%d");
>
> So it just takes the approach that all smsc95xx are going to be eth%d?
Right, and all other drivers that are obviously ethernet-only, including
future drivers.
Arnd
^ permalink raw reply
* [PATCH v2] net: Allow no-cache copy from user on transmit
From: Tom Herbert @ 2011-03-23 17:10 UTC (permalink / raw)
To: davem, netdev
This patch uses __copy_from_user_nocache (from skb_copy_to_page)
on transmit to bypass data cache for a performance improvement.
This functionality is configurable per device using ethtool, the
device must also be doing TX csum offload to enable. It seems
reasonable to set this when the netdevice does not copy or
otherwise touch the data.
This patch was tested using 200 instances of netperf TCP_RR with
1400 byte request and one byte reply. Platform is 16 core AMD x86.
No-cache copy disabled:
672703 tps, 97.13% utilization
50/90/99% latency:244.31 484.205 1028.41
No-cache copy enabled:
702113 tps, 96.16% utilization,
50/90/99% latency 238.56 467.56 956.955
Using 14000 byte request and response sizes demonstrate the
effects more dramatically:
No-cache copy disabled:
79571 tps, 34.34 %utlization
50/90/95% latency 1584.46 2319.59 5001.76
No-cache copy enabled:
83856 tps, 34.81% utilization
50/90/95% latency 2508.42 2622.62 2735.88
Note especially the effect on tail latency (95th percentile).
This seems to provide a nice performance improvement and is
consistent in the tests I ran. Presumably, this would provide
the greatest benfits in the presence of an application workload
stressing the cache and a lot of transmit data happening. I don't
yet see a downside to using this.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/netdevice.h | 10 ++++++++--
include/net/sock.h | 5 +++++
net/core/dev.c | 2 +-
net/core/ethtool.c | 2 +-
4 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 5eeb2cd..52d444f 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1066,6 +1066,7 @@ struct net_device {
#define NETIF_F_NTUPLE (1 << 27) /* N-tuple filters supported */
#define NETIF_F_RXHASH (1 << 28) /* Receive hashing offload */
#define NETIF_F_RXCSUM (1 << 29) /* Receive checksumming offload */
+#define NETIF_F_NOCACHE_COPY (1 << 30) /* Use no-cache copyfromuser */
/* Segmentation offload features */
#define NETIF_F_GSO_SHIFT 16
@@ -1081,7 +1082,7 @@ struct net_device {
/* = all defined minus driver/device-class-related */
#define NETIF_F_NEVER_CHANGE (NETIF_F_HIGHDMA | NETIF_F_VLAN_CHALLENGED | \
NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
-#define NETIF_F_ETHTOOL_BITS (0x3f3fffff & ~NETIF_F_NEVER_CHANGE)
+#define NETIF_F_ETHTOOL_BITS (0x7f3fffff & ~NETIF_F_NEVER_CHANGE)
/* List of features with software fallbacks. */
#define NETIF_F_GSO_SOFTWARE (NETIF_F_TSO | NETIF_F_TSO_ECN | \
@@ -1108,7 +1109,12 @@ struct net_device {
NETIF_F_FRAGLIST)
/* changeable features with no special hardware requirements */
-#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO)
+#define NETIF_F_SOFT_FEATURES (NETIF_F_GSO | NETIF_F_GRO | \
+ NETIF_F_NOCACHE_COPY)
+
+ /* soft features automatically enabled */
+#define NETIF_F_SOFT_FEAT_ENAB (NETIF_F_GSO | NETIF_F_GRO)
+
/* Interface index. Unique device identifier */
int ifindex;
diff --git a/include/net/sock.h b/include/net/sock.h
index da0534d..74ce586 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1401,6 +1401,11 @@ static inline int skb_copy_to_page(struct sock *sk, char __user *from,
if (err)
return err;
skb->csum = csum_block_add(skb->csum, csum, skb->len);
+ } else if (sk->sk_route_caps & NETIF_F_NOCACHE_COPY) {
+ if (!access_ok(VERIFY_READ, from, copy) ||
+ __copy_from_user_nocache(page_address(page) + off,
+ from, copy))
+ return -EFAULT;
} else if (copy_from_user(page_address(page) + off, from, copy))
return -EFAULT;
diff --git a/net/core/dev.c b/net/core/dev.c
index 0b88eba..c3ed95e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5435,7 +5435,7 @@ int register_netdevice(struct net_device *dev)
* software offloads (GSO and GRO).
*/
dev->hw_features |= NETIF_F_SOFT_FEATURES;
- dev->features |= NETIF_F_SOFT_FEATURES;
+ dev->features |= NETIF_F_SOFT_FEAT_ENAB;
dev->wanted_features = dev->features & dev->hw_features;
/* Avoid warning from netdev_fix_features() for GSO without SG */
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index c1a71bb..40b6fe0 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -344,7 +344,7 @@ static const char netdev_features_strings[ETHTOOL_DEV_FEATURE_WORDS * 32][ETH_GS
/* NETIF_F_NTUPLE */ "rx-ntuple-filter",
/* NETIF_F_RXHASH */ "rx-hashing",
/* NETIF_F_RXCSUM */ "rx-checksum",
- "",
+ /* NETIF_F_NOCACHE_COPY */ "tx-nocache-copy"
"",
};
--
1.7.3.1
^ permalink raw reply related
* Re: [PATCH v2 08/16] mlx4_en: Reporting HW revision in ethtool -i
From: Stephen Hemminger @ 2011-03-23 17:06 UTC (permalink / raw)
To: Ben Hutchings
Cc: Yevgeny Petrilin, davem@davemloft.net, netdev@vger.kernel.org,
Eugenia Emantayev
In-Reply-To: <1300896492.2638.13.camel@bwh-desktop>
On Wed, 23 Mar 2011 16:08:12 +0000
Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Wed, 2011-03-23 at 15:54 +0000, Yevgeny Petrilin wrote:
> > > On Wed, 2011-03-23 at 15:10 +0000, Yevgeny Petrilin wrote:
> > > > >
> > > > > This is an abuse of the ethtool_drvinfo::driver field.
> > > > >
> > > > > Your users can use lspci -v, can't they?
> > > > >
> > > > I don't think there is a problem here.
> > > > We have always reported the HW model via Ethtool, we just expanded
> > > the information
> > > > we provide.
> > > > Our users prefer to see the information in ethtool.
> > >
> > > Do you mean 'we documented ethtool -i as the way to get hardware
> > > identification'? That would be a bug in your documentation.
> > >
> > > Ben.
> >
> > This is not what I mean, All the required information can be found in lspci,
> > There are some requests to see part of this information also via ethtool
>
> As Stephen says, the issue here is consistency between drivers.
> Sometimes you just have to say no to customer requests that you abuse a
> standard API.
>
> You could perhaps include some sort of hardware type distinction in the
> firmware version string, if it doesn't already incorporate that.
The pci info is already in bus_info and that can be used by tools.
Alternatively, many drivers splat revision/config info out to dmesg.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox