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

-----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