From: Stephen Hemminger <shemminger@vyatta.com>
To: David Miller <davem@davemloft.net>,
Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Cc: olof@lixom.net, leitao@linux.vnet.ibm.com,
eli@dev.mellanox.co.il, netdev@vger.kernel.org
Subject: Re: [RFC] mark devices with broken LRO implementation
Date: Mon, 6 Dec 2010 09:58:02 -0800 [thread overview]
Message-ID: <20101206095802.2905aea5@nehalam> (raw)
In-Reply-To: <20101206.092855.193714367.davem@davemloft.net>
On Mon, 06 Dec 2010 09:28:55 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Olof Johansson <olof@lixom.net>
> Date: Mon, 6 Dec 2010 11:18:16 -0600
>
> > On Mon, Dec 06, 2010 at 09:10:10AM -0800, Stephen Hemminger wrote:
> >> The kernel uses dev_disable_lro to disable Large Receive Offload
> >> for cases where it is inappropriate. But several drivers do not implement
> >> the required hook. This is a "penalty box" patch to encourage those
> >> drivers to add support for the necessary ethtool set_flags.
> >>
> >> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >
> > pasemi_mac:
> >
> > Acked-by: Olof Johansson <olof@lixom.net>
> >
> >> I only found three drivers that are broken. Normally, I would just fix
> >> them; but since changing state in the device is hardware specific, and
> >> I don't have the hardware or specs to do anything useful to fix it.
> >
> > Thanks. All my hardware is currently in storage due to my relocation, but
> > I'll take a look at it when I have something to run on back. :-)
>
> I don't think we can do what this patch does.
>
> It serves no purpose, as it just means the user is going to have an
> extra headache to turn their driver on.
>
> And %99 of them won't see it, the distribution folks will.
>
> So this is all for nothing.
>
> Better to just work on fixing the problem in the few drivers for
> which the issue exists.
>
> And I'm always happy to receive patches that just plain rip LRO
> support out of such drivers. That's a real legitimate patch unlike
> this one because it keeps the user able to get their driver enabled
> with no fuss and it removes only the improperly functioning feature.
I am less worried about the drivers for embedded devices, the one that
surprises me the mellanox driver. But it looks like that driver doesn't
really do LRO (only GRO).
Subject: mlx4: remove reference to LRO
This device does not do LRO, the current version does GRO.
This patch removes unused inline and changes the configuration
and comments to reflect that. Compile tested only.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/Kconfig | 1 -
drivers/net/mlx4/en_rx.c | 6 +++---
drivers/net/mlx4/mlx4_en.h | 17 -----------------
3 files changed, 3 insertions(+), 21 deletions(-)
--- a/drivers/net/Kconfig 2010-12-06 09:49:11.210488154 -0800
+++ b/drivers/net/Kconfig 2010-12-06 09:49:45.461406671 -0800
@@ -2859,7 +2859,6 @@ config MLX4_EN
tristate "Mellanox Technologies 10Gbit Ethernet support"
depends on PCI && INET
select MLX4_CORE
- select INET_LRO
help
This driver supports Mellanox Technologies ConnectX Ethernet
devices.
--- a/drivers/net/mlx4/en_rx.c 2010-12-06 09:51:38.316270948 -0800
+++ b/drivers/net/mlx4/en_rx.c 2010-12-06 09:51:55.758024934 -0800
@@ -584,7 +584,7 @@ int mlx4_en_process_rx_cq(struct net_dev
if ((cqe->status & cpu_to_be16(MLX4_CQE_STATUS_IPOK)) &&
(cqe->checksum == cpu_to_be16(0xffff))) {
priv->port_stats.rx_chksum_good++;
- /* This packet is eligible for LRO if it is:
+ /* This packet is eligible for GRO if it is:
* - DIX Ethernet (type interpretation)
* - TCP/IP (v4)
* - without IP options
@@ -616,7 +616,7 @@ int mlx4_en_process_rx_cq(struct net_dev
goto next;
}
- /* LRO not possible, complete processing here */
+ /* GRO not possible, complete processing here */
ip_summed = CHECKSUM_UNNECESSARY;
} else {
ip_summed = CHECKSUM_NONE;
@@ -657,7 +657,7 @@ next:
cqe = &cq->buf[index];
if (++polled == budget) {
/* We are here because we reached the NAPI budget -
- * flush only pending LRO sessions */
+ * flush only pending GRO sessions */
goto out;
}
}
--- a/drivers/net/mlx4/mlx4_en.h 2010-12-06 09:50:40.142348439 -0800
+++ b/drivers/net/mlx4/mlx4_en.h 2010-12-06 09:51:59.470397030 -0800
@@ -83,8 +83,6 @@
#define MLX4_EN_ALLOC_ORDER 2
#define MLX4_EN_ALLOC_SIZE (PAGE_SIZE << MLX4_EN_ALLOC_ORDER)
-#define MLX4_EN_MAX_LRO_DESCRIPTORS 32
-
/* Receive fragment sizes; we use at most 4 fragments (for 9600 byte MTU
* and 4K allocations) */
enum {
@@ -268,21 +266,6 @@ struct mlx4_en_rx_ring {
unsigned long packets;
};
-
-static inline int mlx4_en_can_lro(__be16 status)
-{
- return (status & cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
- MLX4_CQE_STATUS_IPV4F |
- MLX4_CQE_STATUS_IPV6 |
- MLX4_CQE_STATUS_IPV4OPT |
- MLX4_CQE_STATUS_TCP |
- MLX4_CQE_STATUS_UDP |
- MLX4_CQE_STATUS_IPOK)) ==
- cpu_to_be16(MLX4_CQE_STATUS_IPV4 |
- MLX4_CQE_STATUS_IPOK |
- MLX4_CQE_STATUS_TCP);
-}
-
struct mlx4_en_cq {
struct mlx4_cq mcq;
struct mlx4_hwq_resources wqres;
next prev parent reply other threads:[~2010-12-06 17:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-06 16:39 [PATCH] ehea: add the correct LRO status at dev->features leitao
2010-12-06 16:48 ` Stephen Hemminger
2010-12-06 16:57 ` Breno Leitao
2010-12-06 17:10 ` [RFC] mark devices with broken LRO implementation Stephen Hemminger
2010-12-06 17:18 ` Olof Johansson
2010-12-06 17:28 ` David Miller
2010-12-06 17:58 ` Stephen Hemminger [this message]
2010-12-06 17:33 ` [PATCH] ehea: add the correct LRO status at dev->features David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20101206095802.2905aea5@nehalam \
--to=shemminger@vyatta.com \
--cc=davem@davemloft.net \
--cc=eli@dev.mellanox.co.il \
--cc=leitao@linux.vnet.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=olof@lixom.net \
--cc=yevgenyp@mellanox.co.il \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.