netdev - Re: [PATCH v3 0/8] net: ethernet: marvell: Assorted fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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