From: Cong Wang <amwang@redhat.com>
To: Stanislaw Gruszka <sgruszka@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: Thu, 17 Jun 2010 18:48:35 +0800 [thread overview]
Message-ID: <4C19FD83.8050507@redhat.com> (raw)
In-Reply-To: <20100615121414.26056d15@dhcp-lab-109.englab.brq.redhat.com>
On 06/15/10 18:14, Stanislaw Gruszka wrote:
> 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.
This depends on if what ethtool_op_set_flags() does is common for
net drivers.
>
> I will think more about that and maybe cook some patches.
>
Yes, please. Cc me when you post patches.
Thanks.
next prev parent reply other threads:[~2010-06-17 10:44 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
2010-06-17 10:48 ` Cong Wang [this message]
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=4C19FD83.8050507@redhat.com \
--to=amwang@redhat.com \
--cc=Ramkrishna.Vepa@exar.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--cc=herbert.xu@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=sgruszka@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 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.