Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 23 8月, 2016 2 次提交
  3. 22 8月, 2016 1 次提交
  5. 19 8月, 2016 2 次提交
  7. 15 8月, 2016 2 次提交
    • H
      cxgb4/cxgb4vf: Add set VF mac address support · 858aa65c
      由 Hariprasad Shenai 提交于 
      Add ndo_set_vf_mac support which allows to set the MAC address
for cxgb4vf interfaces from the host
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      858aa65c
    • H
      cxgb4: Add control net_device for configuring PCIe VF · 7829451c
      由 Hariprasad Shenai 提交于 
      Issue:
For instance, the current APIs assume a 1-to-1 mapping of Network Ports,
Physical Functions and the SR-IOV Virtual Functions of those Physical
Functions. This is not the case with our cards where any Virtual
Function can be hooked up to any Port -- or any number of Ports the
current Linux APIs also assume only 1 Network Interface/Port can be
accessed per Virtual Function.

Another issue is that these APIs assume that the Administrative Driver
is attached to the Physical Function Associated with a Virtual Function.
This is not the case with our card where all administration is performed
by a Driver which is not attached to any of the Physical Functions which
have SR-IOV PCI Capabilities.

Another consequence of these assumptions is the inability to utilize all
of the cards SR-IOV resources. For instance, our cards have SR-IOV
Capabilities on Physical Functions 0..3 and the administrative Driver
attaches to Physical Function 4. Each of the Physical Functions 0..3 can
support up to 16 Virtual Functions. With the current Linux APIs, a
2-Port card would only be able to use the Virtual Functions on Physical
Function 0..1 and not allow the Virtual Functions on Physical Functions
2..3 to be used since there are no Ports 2..3 on a 2-Port card.

Fix:
Since the control node is always the netdevice for all VF ACL commands.
Created a dummy netdevice for each Physical Function from 0 to 3 through
which one could control their VFs. The device won't be associated with
any port, since it doesn't need to transmit/receive. Its purely used
for VF management purpose only. The device will be registered only when
VF for a particular PF is configured using PCI sysfs interface and
unregistered while pci_disable_sriov() for the PF is called.
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7829451c
  9. 31 7月, 2016 1 次提交
  11. 26 7月, 2016 4 次提交
  13. 06 7月, 2016 1 次提交
  15. 26 6月, 2016 1 次提交
    • H
      cxgb4vf: Synchronize access to mailbox · b38066da
      由 Hariprasad Shenai 提交于 
      The issue comes when there are multiple threads attempting to use the
mailbox facility at the same time. The issue is the for the Virtual
Function Driver, the only way to get the Virtual Interface statistics
is to issue mailbox commands to ask the firmware for the VI Stats.
And, because the VI Stats command can only retrieve a smallish number of
stats per mailbox command, we have to issue three mailbox commands in quick
succession. When ethtool or netstat command to get interface stats and
interface up/down is run in a loop for every 0.1 sec, we observed
mailbox collisions. And out of the two commands one would fail with
the present code, since we don't queue the second command.

To overcome the above issue, added a queue to access the mailbox.
Whenever a mailbox command is issued add it to the queue. If its at the
head issue the mailbox command, else wait for the existing command to
complete. Usually command takes less than a milli-second to complete.
Also timeout from the loop, if the command under execution takes
long time to run.

In reality, the number of mailbox access collisions is going to be very
rare since no one runs such abusive script.
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b38066da
  17. 23 6月, 2016 1 次提交
  19. 16 6月, 2016 3 次提交
  21. 09 6月, 2016 1 次提交
  23. 14 5月, 2016 1 次提交
  25. 08 5月, 2016 1 次提交
  27. 05 5月, 2016 3 次提交
  29. 02 5月, 2016 1 次提交
  31. 30 4月, 2016 2 次提交
  33. 27 4月, 2016 9 次提交
  35. 16 4月, 2016 1 次提交
  37. 12 4月, 2016 1 次提交
    • H
      cxgb4: Stop Rx Queues before freeing it up · ebf4dc2b
      由 Hariprasad Shenai 提交于 
      Stop all Ethernet RX Queues before freeing up various Ingress/Egress
Queues, etc. We were seeing cases of Ingress Queues not getting serviced
during the shutdown process leading to Ingress Paths jamming up through
the chip and blocking the shutdown effort itself.

One such case involved the Firmware sending a "Flush Token" through the
ULP-TX -> ULP-RX path for an Ethernet TX Queue being freed in order to
make sure there weren't any remaining TX Work Requests in the pipeline.
But the return path was stalled by Ingress Data unable to be delivered to
the Host because those Ingress Queues were no longer being serviced.

Based on original work by Casey Leedom <leedom@chelsio.com>
Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ebf4dc2b
  39. 07 4月, 2016 2 次提交