netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: Cong Wang <amwang@redhat.com>
Cc: David Miller <davem@davemloft.net>,
	netdev@vger.kernel.org, nhorman@redhat.com,
	herbert.xu@redhat.com, bhutchings@solarflare.com,
	Ramkrishna.Vepa@exar.com
Subject: Re: [v2 Patch 2/2] mlx4: add dynamic LRO disable support
Date: Tue, 15 Jun 2010 12:14:14 +0200	[thread overview]
Message-ID: <20100615121414.26056d15@dhcp-lab-109.englab.brq.redhat.com> (raw)
In-Reply-To: <4C173B57.70601@redhat.com>

On Tue, 15 Jun 2010 16:35:35 +0800
Cong Wang <amwang@redhat.com> wrote:
> > BTW: seems default ethtool_op_set_flags introduce a bug on many
> > devices regarding ETH_FLAG_RXHASH. I think default should
> > be EOPNOTSUPP, and these few devices that actually support RXHASH
> > should have custom ethtool_ops->set_flags
> 
> Hmm, you mean this?
> 
>   if (data & ETH_FLAG_RXHASH)
> +    if (!ops->set_flags)
> +        return -EOPNOTSUPP;
> ....

Not really, but I do not have good idea how patch with fix should
looks.

I dislike fact that we setup ->feature that are not in real supported by
particular device instead of returning EOPNOTSUPP. This actually include
both flags NETIF_F_LRO and NETIF_F_RXHASH. 

Perhaps ethtool_op_set_flags should be removed and drivers should use
only custom version. In particular seems e1000e and sfc use this
function improperly and should have NULL as .set_flags.

I will think more about that and maybe cook some patches.

Stanislaw

  reply	other threads:[~2010-06-15 10:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-09 10:05 [v2 Patch 1/2] s2io: add dynamic LRO disable support Amerigo Wang
2010-06-09 10:05 ` [v2 Patch 2/2] mlx4: " Amerigo Wang
2010-06-09 11:05   ` Stanislaw Gruszka
2010-06-15  8:35     ` Cong Wang
2010-06-15 10:14       ` Stanislaw Gruszka [this message]
2010-06-17 10:48         ` Cong Wang
2010-06-09 14:00 ` [v2 Patch 1/2] s2io: " Ben Hutchings
2010-06-09 18:52   ` Ramkrishna Vepa
2010-06-15  8:26     ` Cong Wang
2010-06-15 16:07       ` Ramkrishna Vepa
2010-06-15 17:21         ` 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=20100615121414.26056d15@dhcp-lab-109.englab.brq.redhat.com \
    --to=sgruszka@redhat.com \
    --cc=Ramkrishna.Vepa@exar.com \
    --cc=amwang@redhat.com \
    --cc=bhutchings@solarflare.com \
    --cc=davem@davemloft.net \
    --cc=herbert.xu@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).