Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 21 2月, 2017 3 次提交
  3. 20 2月, 2017 1 次提交
  5. 16 2月, 2017 1 次提交
  7. 21 1月, 2017 1 次提交
    • A
      qed: avoid possible stack overflow in qed_ll2_acquire_connection · 0629a330
      由 Arnd Bergmann 提交于 
      struct qed_ll2_info is rather large, so putting it on the stack
can cause an overflow, as this warning tries to tell us:

drivers/net/ethernet/qlogic/qed/qed_ll2.c: In function 'qed_ll2_start':
drivers/net/ethernet/qlogic/qed/qed_ll2.c:2159:1: error: the frame size of 1056 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

qed_ll2_start_ooo() already uses a dynamic allocation for the structure
to work around that problem, and we could do the same in qed_ll2_start()
as well as qed_roce_ll2_start(), but since the structure is only
used to pass a couple of initialization values here, it seems nicer
to replace it with a different structure.

Lacking any idea for better naming, I'm adding 'struct qed_ll2_conn',
which now contains all the initialization data, and this now simply
gets copied into struct qed_ll2_info rather than assigning all members
one by one.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0629a330
  9. 18 1月, 2017 1 次提交
  11. 02 1月, 2017 7 次提交
  13. 18 12月, 2016 1 次提交
  15. 14 12月, 2016 1 次提交
  17. 06 12月, 2016 1 次提交
  19. 03 12月, 2016 2 次提交
  21. 01 12月, 2016 2 次提交
    • M
      qed*: Handle-based L2-queues. · 3da7a37a
      由 Mintz, Yuval 提交于 
      The driver needs to maintain several FW/HW-indices for each one of
its queues. Currently, that mapping is done by the QED where it uses
an rx/tx array of so-called hw-cids, populating them whenever a new
queue is opened and clearing them upon destruction of said queues.

This maintenance is far from ideal - there's no real reason why
QED needs to maintain such a data-structure. It becomes even worse
when considering the fact that the PF's queues and its child VFs' queues
are all mapped into the same data-structure.
As a by-product, the set of parameters an interface needs to supply for
queue APIs is non-trivial, and some of the variables in the API
structures have different meaning depending on their exact place
in the configuration flow.

This patch re-organizes the way L2 queues are configured and maintained.
In short:
  - Required parameters for queue init are now well-defined.
  - Qed would allocate a queue-cid based on parameters.
    Upon initialization success, it would return a handle to caller.
  - Queue-handle would be maintained by entity requesting queue-init,
    not necessarily qed.
  - All further queue-APIs [update, destroy] would use the opaque
    handle as reference for the queue instead of various indices.

The possible owners of such handles:
  - PF queues [qede] - complete handles based on provided configuration.
  - VF queues [qede] - fw-context-less handles, containing only relative
    information; Only the PF-side would need the absolute indices
    for configuration, so they're omitted here.
  - VF queues [qed, PF-side] - complete handles based on VF initialization.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3da7a37a
    • M
      qed: Optimize qed_chain datapath usage · 6d937acf
      由 Mintz, Yuval 提交于 
      The chain structure and functions are widely used by the qed* modules,
both for configuration and datapath.
E.g., qede's Tx has one such chain and its Rx has two.

Currently, the strucutre's fields which are required for datapath
related functions [produce/consume] are intertwined with fields which
are required only for configuration purposes [init/destroy/etc.].

This patch re-arranges the chain structure so that all the fields which
are required for datapath usage could reside in a single cacheline instead
of the two which are required today.
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d937acf
  23. 11 11月, 2016 2 次提交
  25. 10 11月, 2016 1 次提交
    • M
      qed: Prevent stack corruption on MFW interaction · bb480242
      由 Mintz, Yuval 提交于 
      Driver uses a union for copying data to & from management firmware
when interacting with it.
Problem is that the function always copies sizeof(union) while commit
2edbff8d ("qed: Learn resources from management firmware") is casting
a union elements which is of smaller size [24-byte instead of 88-bytes].

Also, the union contains some inappropriate elements which increase its
size [should have been 32-bytes]. While this shouldn't corrupt other
PF messages to the MFW [as management firmware enforces permissions so
that each PF is allowed to write only to its own mailbox] we fix this
here as well.

Fixes: 2edbff8d ("qed: Learn resources from management firmware")
Signed-off-by: NYuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bb480242
  27. 01 11月, 2016 7 次提交
  29. 23 10月, 2016 2 次提交
  31. 19 10月, 2016 2 次提交
  33. 14 10月, 2016 5 次提交
    • M
      qed: Fix possible race when reading firmware return code. · d5df7688
      由 Manish Chopra 提交于 
      While handling SPQ ramrod completion, there is a possible race
where driver might not read updated fw return code based on
ramrod completion done. This patch ensures that fw return code
is written first and then completion done flag is updated
using appropriate memory barriers.
Signed-off-by: NManish Chopra <manish.chopra@caviumnetworks.com>
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d5df7688
    • Y
      qed: Handle malicious VFs events · 7eff82b0
      由 Yuval Mintz 提交于 
      Malicious VFs might be caught in several different methods:
  - Misusing their bar permission and being blocked by hardware.
  - Misusing their fastpath logic and being blocked by firmware.
  - Misusing their interaction with their PF via hw-channel,
    and being blocked by PF driver.

On the first two items, firmware would indicate to driver that
the VF is to be considered malicious, but would sometime still
allow the VF to communicate with the PF [depending on the exact
nature of the malicious activity done by the VF].
The current existing logic on the PF side lacks handling of such events,
and might allow the PF to perform some incorrect configuration on behalf
of a VF that was previously indicated as malicious.

The new scheme is simple -
Once the PF determines a VF is malicious it would:
 a. Ignore any further requests on behalf of the VF-driver.
 b. Prevent any configurations initiated by the hyperuser for
    the malicious VF, as firmware isn't willing to serve such.

The malicious indication would be cleared upon the VF flr,
after which it would become usable once again.
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7eff82b0
    • Y
      qed: Allow chance for fast ramrod completions · c59f5291
      由 Yuval Mintz 提交于 
      Whenever a ramrod is being sent for some device configuration,
the driver is going to sleep at least 5ms between each iteration
of polling on the completion of the ramrod.

However, in almost every configuration scenario the firmware
would be able to comply and complete the ramrod in a manner of
several usecs. This is especially important in cases where there
might be a lot of sequential configurations applying to the hardware
[e.g., RoCE], in which case the existing scheme might cause some
visible user delays.

This patch changes the completion scheme - instead of immediately
starting to sleep for a 'long' period, allow the device to quickly
poll on the first iteration after a couple of usecs.
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c59f5291
    • Y
      qed*: Allow unicast filtering · 7b7e70f9
      由 Yuval Mintz 提交于 
      Apparently qede fails to set IFF_UNICAST_FLT, and as a result is not
actually performing unicast MAC filtering.
While we're at it - relax a hard-coded limitation that limits each
interface into using at most 15 unicast MAC addresses before turning
promiscuous. Instead utilize the HW resources to their limit.
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7b7e70f9
    • Y
      qed: Pass MAC hints to VFs · c3aaa403
      由 Yuval Mintz 提交于 
      Some hypervisors can support MAC hints to their VFs.
Even though we don't have such a hypervisor API in linux, we add
sufficient logic for the VF to be able to receive such hints and
set the mac accordingly - as long as the VF has not been set with
a MAC already.
Signed-off-by: NYuval Mintz <Yuval.Mintz@caviumnetworks.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c3aaa403