[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20140523.153616.2078296737930596480.davem@davemloft.net>
Date: Fri, 23 May 2014 15:36:16 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: ezequiel.garcia@...e-electrons.com
Cc: netdev@...r.kernel.org, thomas.petazzoni@...e-electrons.com,
sebastian.hesselbarth@...il.com,
gregory.clement@...e-electrons.com, alior@...vell.com,
tawfik@...vell.com, andrew@...n.ch
Subject: Re: [PATCH v3 0/8] net: ethernet: marvell: Assorted fixes
From: Ezequiel Garcia <ezequiel.garcia@...e-electrons.com>
Date: Thu, 22 May 2014 20:06:55 -0300
> New round for this assorted fixes and clean-up series. There is more room for
> clean-ups, and I'll start preparing more patches once these are accepted.
>
> This series consists of cleanups and minor improvements on mvneta, mv643xx_eth
> and mvmdio drivers. None of the patches imply any functionality change, except
> for the patch six "Change the number of default rx queues to one".
>
> This patch reduces the driver's allocated resources and makes the multiqueue
> path in the poll function not get taken. The previous patchset contains more
> details:
>
> http://permalink.gmane.org/gmane.linux.network/315015
>
> As usual, any feedback on this will be well received!
Series applied to net-next, but some comments:
1) Never use web sites to reference informative material, instead put it
all explicitly into the commit message in your posting.
Web sites and archives come and go, the commit message is forever and
readily available to someone studying your changes.
2) Just get rid of that MVNETA_RX_POLL_WEIGHT and simply use the
generic default NAPI_POLL_WEIGHT which has the same value.
Any local NAPI weight selection must be done for a good reason and
be fully documented with performance metrics et al.
3) I know you inherited this, but the MTU change failure behavior is
not so great. If the system is low on memory it could fail and losing
an interface completely during an MTU change is extremely poor behavior.
I would suggest holding onto the old allocated TXQ resources, and
restoring them if the allocation of the new ones fail.
That way the MTU change itself would fail, but the interface would
remain up with the original MTU.
Please make sure that you properly revert the MTU adjustment in
this failure path.
Thanks.
--
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