4be18885d1
There's a possible race in multiple VF scenarios for base driver users that use the optional APIs ecore_iov_pf_get_and_clear_pending_events, ecore_iov_pf_add_pending_events. If the client doesn't synchronize the two calls, it's possible for the PF to clear a VF pending message indication without ever getting it [as 'get & clear' isn't atomic], leading to VF timeout on the command. The solution is to switch into a per-VF indication rather than having a bitfield for the various VFs with pending events. As part of the solution, the setting/clearing of the indications is done internally by base driver. As a result, ecore_iov_pf_add_pending_events is no longer needed and ecore_iov_pf_get_and_clear_pending_events loses the 'and_clear' from its name as its now a proper getter. A VF would be considered 'pending' [I.e., get_pending_events() should have '1' for it in its bitfield] beginning with the PF's base driver recognizing a message sent by that VF [in SP_DPC] and ending only when that VF message is processed. Signed-off-by: Rasesh Mody <rasesh.mody@cavium.com> |
||
---|---|---|
.. | ||
af_packet | ||
ark | ||
avp | ||
bnx2x | ||
bnxt | ||
bonding | ||
cxgbe | ||
dpaa2 | ||
e1000 | ||
ena | ||
enic | ||
failsafe | ||
fm10k | ||
i40e | ||
ixgbe | ||
kni | ||
liquidio | ||
mlx4 | ||
mlx5 | ||
nfp | ||
null | ||
pcap | ||
qede | ||
ring | ||
sfc | ||
szedata2 | ||
tap | ||
thunderx | ||
vhost | ||
virtio | ||
vmxnet3 | ||
xenvirt | ||
Makefile |