[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100621090214.GB3240@dhcp-lab-161.englab.brq.redhat.com>
Date: Mon, 21 Jun 2010 11:02:15 +0200
From: Stanislaw Gruszka <sgruszka@...hat.com>
To: Cong Wang <amwang@...hat.com>
Cc: netdev@...r.kernel.org, nhorman@...hat.com, herbert.xu@...hat.com,
bhutchings@...arflare.com, Ramkrishna.Vepa@...r.com,
davem@...emloft.net
Subject: Re: [v3 Patch 2/2] mlx4: add dynamic LRO disable support
On Mon, Jun 21, 2010 at 10:23:00AM +0800, Cong Wang wrote:
> On 06/18/10 19:09, Stanislaw Gruszka wrote:
>> On Fri, Jun 18, 2010 at 06:55:38AM -0400, Amerigo Wang wrote:
>>> +static int mlx4_ethtool_op_set_flags(struct net_device *dev, u32 data)
>>> +{
>>> + struct mlx4_en_priv *priv = netdev_priv(dev);
>>> + struct mlx4_en_dev *mdev = priv->mdev;
>>> + int rc = 0;
>>> + int changed = 0;
>>> +
>>> + if (data& (ETH_FLAG_NTUPLE | ETH_FLAG_RXHASH))
>>> + return -EOPNOTSUPP;
As we are here, better would be
if (data & ~ETH_FLAG_LRO)
return -EOPNOTSUPP;
code will persist correct when someone add new flags.
>>> +
>>> + if (data& ETH_FLAG_LRO) {
>>> + if (!(dev->features& NETIF_F_LRO))
>>> + changed = 1;
>>> + } else if (dev->features& NETIF_F_LRO) {
>>> + changed = 1;
>>> + mdev->profile.num_lro = 0;
>>
>> Everything fine except that, what for you zero num_lro value?
>>
>> If we set it to zero it will stay zero and we will not create
>> proper number of lro descriptors in mlx4_en_create_rx_ring()
>> (called from mlx4_en_set_ringparam() -> mlx4_en_alloc_resources())
>> when someone enable LRO again on.
>>
>
> Huh? Isn't ->num_lro which controls LRO of mlx4 driver?
It is, but only in mlx4_en_add() just before register_netdev(),
when we setup default dev->features. Otherwise dev->features
tells if LRO is enabled or disabled.
This realize me, that we should not dev->features |= NETIF_F_LRO
if mdev->profile.num_lro == 0 .
Stanislaw
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists