Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 8月, 2021 1 次提交
    • V
      igc: Add support for PTP getcrosststamp() · a90ec848
      由 Vinicius Costa Gomes 提交于 
      i225 supports PCIe Precision Time Measurement (PTM), allowing us to
support the PTP_SYS_OFFSET_PRECISE ioctl() in the driver via the
getcrosststamp() function.

The easiest way to expose the PTM registers would be to configure the PTM
dialogs to run periodically, but the PTP_SYS_OFFSET_PRECISE ioctl()
semantics are more aligned to using a kind of "one-shot" way of retrieving
the PTM timestamps. But this causes a bit more code to be written: the
trigger registers for the PTM dialogs are not cleared automatically.

i225 can be configured to send "fake" packets with the PTM
information, adding support for handling these types of packets is
left for the future.

PTM improves the accuracy of time synchronization, for example, using
phc2sys, while a simple application is sending packets as fast as
possible. First, without .getcrosststamp():

phc2sys[191.382]: enp4s0 sys offset      -959 s2 freq    -454 delay   4492
phc2sys[191.482]: enp4s0 sys offset       798 s2 freq   +1015 delay   4069
phc2sys[191.583]: enp4s0 sys offset       962 s2 freq   +1418 delay   3849
phc2sys[191.683]: enp4s0 sys offset       924 s2 freq   +1669 delay   3753
phc2sys[191.783]: enp4s0 sys offset       664 s2 freq   +1686 delay   3349
phc2sys[191.883]: enp4s0 sys offset       218 s2 freq   +1439 delay   2585
phc2sys[191.983]: enp4s0 sys offset       761 s2 freq   +2048 delay   3750
phc2sys[192.083]: enp4s0 sys offset       756 s2 freq   +2271 delay   4061
phc2sys[192.183]: enp4s0 sys offset       809 s2 freq   +2551 delay   4384
phc2sys[192.283]: enp4s0 sys offset      -108 s2 freq   +1877 delay   2480
phc2sys[192.383]: enp4s0 sys offset     -1145 s2 freq    +807 delay   4438
phc2sys[192.484]: enp4s0 sys offset       571 s2 freq   +2180 delay   3849
phc2sys[192.584]: enp4s0 sys offset       241 s2 freq   +2021 delay   3389
phc2sys[192.684]: enp4s0 sys offset       405 s2 freq   +2257 delay   3829
phc2sys[192.784]: enp4s0 sys offset        17 s2 freq   +1991 delay   3273
phc2sys[192.884]: enp4s0 sys offset       152 s2 freq   +2131 delay   3948
phc2sys[192.984]: enp4s0 sys offset      -187 s2 freq   +1837 delay   3162
phc2sys[193.084]: enp4s0 sys offset     -1595 s2 freq    +373 delay   4557
phc2sys[193.184]: enp4s0 sys offset       107 s2 freq   +1597 delay   3740
phc2sys[193.284]: enp4s0 sys offset       199 s2 freq   +1721 delay   4010
phc2sys[193.385]: enp4s0 sys offset      -169 s2 freq   +1413 delay   3701
phc2sys[193.485]: enp4s0 sys offset       -47 s2 freq   +1484 delay   3581
phc2sys[193.585]: enp4s0 sys offset       -65 s2 freq   +1452 delay   3778
phc2sys[193.685]: enp4s0 sys offset        95 s2 freq   +1592 delay   3888
phc2sys[193.785]: enp4s0 sys offset       206 s2 freq   +1732 delay   4445
phc2sys[193.885]: enp4s0 sys offset      -652 s2 freq    +936 delay   2521
phc2sys[193.985]: enp4s0 sys offset      -203 s2 freq   +1189 delay   3391
phc2sys[194.085]: enp4s0 sys offset      -376 s2 freq    +955 delay   2951
phc2sys[194.185]: enp4s0 sys offset      -134 s2 freq   +1084 delay   3330
phc2sys[194.285]: enp4s0 sys offset       -22 s2 freq   +1156 delay   3479
phc2sys[194.386]: enp4s0 sys offset        32 s2 freq   +1204 delay   3602
phc2sys[194.486]: enp4s0 sys offset       122 s2 freq   +1303 delay   3731

Statistics for this run (total of 2179 lines), in nanoseconds:
  average: -1.12
  stdev: 634.80
  max: 1551
  min: -2215

With .getcrosststamp() via PCIe PTM:

phc2sys[367.859]: enp4s0 sys offset         6 s2 freq   +1727 delay      0
phc2sys[367.959]: enp4s0 sys offset        -2 s2 freq   +1721 delay      0
phc2sys[368.059]: enp4s0 sys offset         5 s2 freq   +1727 delay      0
phc2sys[368.160]: enp4s0 sys offset        -1 s2 freq   +1723 delay      0
phc2sys[368.260]: enp4s0 sys offset        -4 s2 freq   +1719 delay      0
phc2sys[368.360]: enp4s0 sys offset        -5 s2 freq   +1717 delay      0
phc2sys[368.460]: enp4s0 sys offset         1 s2 freq   +1722 delay      0
phc2sys[368.560]: enp4s0 sys offset        -3 s2 freq   +1718 delay      0
phc2sys[368.660]: enp4s0 sys offset         5 s2 freq   +1725 delay      0
phc2sys[368.760]: enp4s0 sys offset        -1 s2 freq   +1721 delay      0
phc2sys[368.860]: enp4s0 sys offset         0 s2 freq   +1721 delay      0
phc2sys[368.960]: enp4s0 sys offset         0 s2 freq   +1721 delay      0
phc2sys[369.061]: enp4s0 sys offset         4 s2 freq   +1725 delay      0
phc2sys[369.161]: enp4s0 sys offset         1 s2 freq   +1724 delay      0
phc2sys[369.261]: enp4s0 sys offset         4 s2 freq   +1727 delay      0
phc2sys[369.361]: enp4s0 sys offset         8 s2 freq   +1732 delay      0
phc2sys[369.461]: enp4s0 sys offset         7 s2 freq   +1733 delay      0
phc2sys[369.561]: enp4s0 sys offset         4 s2 freq   +1733 delay      0
phc2sys[369.661]: enp4s0 sys offset         1 s2 freq   +1731 delay      0
phc2sys[369.761]: enp4s0 sys offset         1 s2 freq   +1731 delay      0
phc2sys[369.861]: enp4s0 sys offset        -5 s2 freq   +1725 delay      0
phc2sys[369.961]: enp4s0 sys offset        -4 s2 freq   +1725 delay      0
phc2sys[370.062]: enp4s0 sys offset         2 s2 freq   +1730 delay      0
phc2sys[370.162]: enp4s0 sys offset        -7 s2 freq   +1721 delay      0
phc2sys[370.262]: enp4s0 sys offset        -3 s2 freq   +1723 delay      0
phc2sys[370.362]: enp4s0 sys offset         1 s2 freq   +1726 delay      0
phc2sys[370.462]: enp4s0 sys offset        -3 s2 freq   +1723 delay      0
phc2sys[370.562]: enp4s0 sys offset        -1 s2 freq   +1724 delay      0
phc2sys[370.662]: enp4s0 sys offset        -4 s2 freq   +1720 delay      0
phc2sys[370.762]: enp4s0 sys offset        -7 s2 freq   +1716 delay      0
phc2sys[370.862]: enp4s0 sys offset        -2 s2 freq   +1719 delay      0

Statistics for this run (total of 2179 lines), in nanoseconds:
  average: 0.14
  stdev: 5.03
  max: 48
  min: -27

For reference, the statistics for runs without PCIe congestion show
that the improvements from enabling PTM are less dramatic. For two
runs of 16466 entries:
  without PTM: avg -0.04 stdev 10.57 max 39 min -42
  with PTM: avg 0.01 stdev 4.20 max 19 min -16

One possible explanation is that when PTM is not enabled, and there's a lot
of traffic in the PCIe fabric, some register reads will take more time
than the others because of congestion on the PCIe fabric.

When PTM is enabled, even if the PTM dialogs take more time to
complete under heavy traffic, the time measurements do not depend on
the time to read the registers.

This was implemented following the i225 EAS version 0.993.
Signed-off-by: NVinicius Costa Gomes <vinicius.gomes@intel.com>
Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      a90ec848
  3. 20 7月, 2021 1 次提交
  5. 17 7月, 2021 4 次提交
  7. 02 7月, 2021 1 次提交
  9. 05 6月, 2021 1 次提交
  11. 21 5月, 2021 3 次提交
  13. 17 4月, 2021 2 次提交
    • E
      igc: enable auxiliary PHC functions for the i225 · 87938851
      由 Ederson de Souza 提交于 
      The i225 device offers a number of special PTP Hardware Clock features on
the Software Defined Pins (SDPs) - much like i210, which is used as
inspiration for this patch. It enables two possible functions, namely
time stamping external events and periodic output signals.

The assignment of PHC functions to the four SDP can be freely chosen by
the user.

For the external events time stamping, when the SDP (configured as input
by user) level changes, an interrupt is generated and the kernel
Precision Time Protocol (PTP) is informed.

For the periodic output signals, the i225 is configured to generate them
(so the SDP level will change periodically) and the driver also has to
keep updating the time of the next level change. However, this work is
not necessary for some frequencies as the i225 takes care of them
(namely, anything with a half-cycle of 500ms, 250ms, 125ms or < 70ms).

While i225 allows up to four timers to be used to source the time used
on the external events or output signals, this patch uses only one of
those timers. Main reason is to keep it simple, as it's not clear how
these extra timers would be exposed to users. Note that currently a NIC
can expose a single PTP device.
Signed-off-by: NEderson de Souza <ederson.desouza@intel.com>
Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      87938851
    • E
      igc: Enable internal i225 PPS · 64433e5b
      由 Ederson de Souza 提交于 
      The i225 device can produce one interrupt on the full second, much
like i210 - from where this patch is inspired.

This patch sets up the full second interruption on the i225 and when
receiving it, it sends a PPS event to PTP (Precision Time Protocol)
kernel subsystem.

The PTP subsystem exposes the PPS events via ioctl and sysfs, and one
can use the `testptp` tool (tools/testing/selftests/ptp) to check that
the events are being generated.
Signed-off-by: NEderson de Souza <ederson.desouza@intel.com>
Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      64433e5b
  15. 30 3月, 2021 2 次提交
    • A
      igc: Add support for XDP_TX action · 73f1071c
      由 Andre Guedes 提交于 
      Add support for XDP_TX action which enables XDP programs to transmit
back receiving frames.

I225 controller has only 4 Tx hardware queues. Since XDP programs may
not even issue an XDP_TX action, this patch doesn't reserve dedicated
queues just for XDP like other Intel drivers do. Instead, the queues
are shared between the network stack and XDP. The netdev queue lock is
used to ensure mutual exclusion.

Since frames can now be transmitted via XDP_TX, the igc_tx_buffer
structure is modified so we are able to save a reference to the xdp
frame for later clean up once the packet is transmitted. The tx_buffer
is mapped to either a skb or a xdpf so we use a union to save the skb
or xdpf pointer and have a bit in tx_flags to indicate which field to
use.

This patch has been tested with the sample app "xdp2" located in
samples/bpf/ dir.
Signed-off-by: NAndre Guedes <andre.guedes@intel.com>
Signed-off-by: NVedang Patel <vedang.patel@intel.com>
Signed-off-by: NJithu Joseph <jithu.joseph@intel.com>
Reviewed-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      73f1071c
    • A
      igc: Add initial XDP support · 26575105
      由 Andre Guedes 提交于 
      Add the initial XDP support to the igc driver. For now, only XDP_PASS,
XDP_DROP, XDP_ABORTED actions are supported. Upcoming patches will add
support for the remaining XDP actions.

XDP configuration helpers are defined in a new file, igc_xdp.c. These
helpers are utilized in igc_main.c to implement the ndo_bpf callback.
XDP-related code that belongs to the driver's hot path is landed in
igc_main.c.

By default, the driver uses Rx buffers with 2 KB size. When XDP is
enabled, it uses larger buffers so we have enough space to accommodate
the headroom and tailroom required by XDP infrastructure. Also, the
driver doesn't support XDP functionality with frames that span over
multiple buffers so jumbo frames are not allowed for now.

The approach implemented follows the approach implemented in other Intel
drivers as much as possible for the sake of consistency across the
drivers.

Quick comment regarding igc_build_skb(): this patch doesn't touch it
because the function is never called. It seems its support is
incomplete/in progress. The function was added by commit 0507ef8a
("igc: Add transmit and receive fastpath and interrupt handlers") but
ring_uses_build_skb() always return False since the IGC_RING_FLAG_RX_
BUILD_SKB_ENABLED isn't set anywhere in the driver code.

This patch has been tested with the sample app "xdp1" located in
samples/bpf/ dir.
Signed-off-by: NAndre Guedes <andre.guedes@intel.com>
Signed-off-by: NVedang Patel <vedang.patel@intel.com>
Signed-off-by: NJithu Joseph <jithu.joseph@intel.com>
Reviewed-by: NMaciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: NDvora Fuxbrumer <dvorax.fuxbrumer@linux.intel.com>
Signed-off-by: NTony Nguyen <anthony.l.nguyen@intel.com>
      26575105
  17. 29 3月, 2021 2 次提交
  19. 12 3月, 2021 1 次提交
  21. 04 2月, 2021 2 次提交
  23. 29 9月, 2020 2 次提交
  25. 10 9月, 2020 1 次提交
  27. 30 6月, 2020 2 次提交
  29. 26 6月, 2020 1 次提交
    • J
      net/intel: remove driver versions from Intel drivers · 34a2a3b8
      由 Jeff Kirsher 提交于 
      As with other networking drivers, remove the unnecessary driver version
from the Intel drivers. The ethtool driver information and module version
will then report the kernel version instead.

For ixgbe, i40e and ice drivers, the driver passes the driver version to
the firmware to confirm that we are up and running.  So we now pass the
value of UTS_RELEASE to the firmware.  This adminq call is required per
the HAS document.  The Device then sends an indication to the BMC that the
PF driver is present. This is done using Host NC Driver Status Indication
in NC-SI Get Link command or via the Host Network Controller Driver Status
Change AEN.

What the BMC may do with this information is implementation-dependent, but
this is a standard NC-SI 1.1 command we honor per the HAS.

CC: Bruce Allan <bruce.w.allan@intel.com>
CC: Jesse Brandeburg <jesse.brandeburg@intel.com>
CC: Alek Loktionov <aleksandr.loktionov@intel.com>
CC: Kevin Liedtke <kevin.d.liedtke@intel.com>
CC: Aaron Rowden <aaron.f.rowden@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
Co-developed-by: NJacob Keller <jacob.e.keller@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
      34a2a3b8
  31. 29 5月, 2020 1 次提交
  33. 23 5月, 2020 4 次提交
    • A
      igc: Change adapter->nfc_rule_lock to mutex · 42fc5dc0
      由 Andre Guedes 提交于 
      This patch changes adapter->nfc_rule_lock type from spin_lock to mutex
so we avoid unnecessary busy waiting on lock contention.

A closer look at the execution context of NFC rule API users shows that
all of them run in process context. The API users are: ethtool ops,
igc_configure(), called when interface is brought up by user or reset
workequeue thread, igc_down(), called when interface is brought down,
and igc_remove(), called when driver is unloaded.
Signed-off-by: NAndre Guedes <andre.guedes@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      42fc5dc0
    • A
      igc: Refactor igc_ethtool_update_nfc_rule() · 36fa2152
      由 Andre Guedes 提交于 
      Current implementation of igc_ethtool_update_nfc_rule() is a bit
convoluted since it handles too many things: rule lookup, deletion
and addition. This patch breaks it into three functions so we simplify
the code and improve code reuse.

Code related to rule lookup is refactored out to a new function called
igc_get_nfc_rule().

Code related to rule addition is refactored out to a new function called
igc_add_nfc_rule(). This function enables the rule in hardware and adds
it to the adapter's list.

Code related to rule deletion is refactored out to a new function called
igc_del_nfc_rule(). This function disables the rule in hardware, removes
it from adapter's list, and deletes it.

As a byproduct of this refactoring, igc_enable_nfc_rule() and
igc_disable_nfc_rule() are moved to igc_main.c since they are not used
in igc_ethtool.c anymore, and igc_restore_nfc_rules() and igc_nfc_rule_
exit() are moved around to avoid forward declaration.

Also, since this patch already touches igc_ethtool_get_nfc_rule(), it
takes the opportunity to remove the 'match_flags' check. Empty flags
are not allowed to be added so no need to check that.
Signed-off-by: NAndre Guedes <andre.guedes@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      36fa2152
    • A
      igc: Fix NFC rules restoration · d957c601
      由 Andre Guedes 提交于 
      When network interface is brought up, the driver re-enables the NFC
rules previously configured. However, this is done in reverse order
the rules were added and hardware filters are configured differently.

For example, consider the following rules:

$ ethtool -N eth0 flow-type ether dst 00:00:00:00:00:AA queue 0
$ ethtool -N eth0 flow-type ether dst 00:00:00:00:00:BB queue 1
$ ethtool -N eth0 flow-type ether dst 00:00:00:00:00:CC queue 2
$ ethtool -N eth0 flow-type ether dst 00:00:00:00:00:DD queue 3

RAL/RAH registers are configure so filter index 1 has address ending
with AA, filter index 2 has address ending in BB, and so on.

If we bring the interface down and up again, RAL/RAH registers are
configured so filter index 1 has address ending in DD, filter index 2
has CC, and so on. IOW, in reverse order we had before bringing the
interface down.

This issue can be fixed by traversing adapter->nfc_rule_list in
backwards when restoring the rules. Since hlist doesn't support
backwards traversal, this patch replaces it by list_head and fixes
igc_restore_nfc_rules() accordingly.
Signed-off-by: NAndre Guedes <andre.guedes@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d957c601
    • A
      igc: Fix 'sw_idx' type in struct igc_nfc_rule · d3ba9e6f
      由 Andre Guedes 提交于 
      The 'sw_idx' field from 'struct igc_nfc_rule' is u16 type but it is
assigned an u32 value in igc_ethtool_init_nfc_rule(). This patch changes
'sw_idx' type to u32 so they match. Also, it makes more sense to call
this field 'location' since it holds the NFC rule location.
Signed-off-by: NAndre Guedes <andre.guedes@intel.com>
Tested-by: NAaron Brown <aaron.f.brown@intel.com>
Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      d3ba9e6f
  35. 22 5月, 2020 5 次提交
  37. 21 5月, 2020 2 次提交
  39. 20 5月, 2020 2 次提交