RE: [net-next PATCH 0/4] be2net: patch set

[Sathya Perla <sathya.perla@broadcom.com>]

> -----Original Message-----
> From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Sathya Perla
> Sent: Wednesday, July 27, 2016 2:56 PM
> To: netdev@vger.kernel.org
> Subject: [net-next PATCH 0/4] be2net: patch set
>
> Hi David, pls consider applying this patch-set to the net-next tree.
>
> Patch 1 fixes the driver to workaournd a bug in the Lancer FW in the
vlan-config cmd processing. The FW in some
> cases clears the vlan-promisc setting even if it cannot apply the vlan
filter. The driver has no means of knowing if
> the vlan-promisc setting has been cleared or not. This patch now
explicitly clears the vlan-promisc setting via the
> RX-Filter cmd and then tries to program the vlan-list.
>
> Patch 2 fixes the failure path in the vlan vid add code.
> The driver currently removes a new vid from the adapter->vids[] array if
> be_vid_config() returns an error, which occurs when there is an error in
HW/FW. This is wrong. After the HW/FW
> error is recovered from, we need the complete vids[] array to re-program
the vlan list.
>
> Patch 3 fixes the ndo_set_rx_mode() path to avoid unnecessary multicast
list updates to the FW. Each time the
> ndo_set_rx_mode() routine is called, the driver programs the multicast
list in the adapter without checking if
> there are any changes to the list. This leads to a flood of RX_FILTER
cmds when a number of vlan interfaces are
> configured over the device, as the ndo_ gets called for each vlan
interface. To avoid this, we now use
> __dev_mc_sync() and __dev_uc_sync() API, but only to detect if there is
a change in the mc/uc lists. Now that we
> use this API, the code has to be-designed to issue these API calls for
each invocation of the ndo_ call.
>
> Patch 4 replaces polling with sleeping in the FW completion path.
> The ndo_set_rx_mode() and ndo_add/del_vxlan_port() calls may be called
with BHs disabled. The driver currently
> issues the required cmds to the FW in these contexts and polls on
completions from the FW, while BHs remain
> disabled.  This can cause either packet loss or packet reception to be
delayed on that CPU.  This patch defers
> processing of the above cmds to a separate workqueue. With this change,
FW cmds are now issued only in
> process context. Now that the FW cmds are issued only in process
context, they can sleep waiting for a
> completion instead of polling.

David, do you want me to re-submit this patch-set after net-next re-opens
or would you consider applying this now itself?

thanks,
-Sathya