XDP-hints kfuncs for Intel driver igc #4802
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Upstream branch: 6a9f5cd |
|
Upstream branch: 6a9f5cd |
kernel-patches-bot
force-pushed
the
series/731202=>bpf-next
branch
from
1a9ced1
to
c9c5ed2
Compare
kernel-patches-bot
force-pushed
the
bpf-next_base
branch
from
e1443b3
to
6bde8df
Compare
|
Upstream branch: 9a321fd |
kernel-patches-bot
force-pushed
the
series/731202=>bpf-next
branch
from
c9c5ed2
to
26b7676
Compare
kernel-patches-bot
force-pushed
the
bpf-next_base
branch
from
6bde8df
to
40fe664
Compare
|
Upstream branch: 9a321fd |
kernel-patches-bot
force-pushed
the
series/731202=>bpf-next
branch
from
26b7676
to
4de348e
Compare
kernel-patches-bot
force-pushed
the
bpf-next_base
branch
from
40fe664
to
77c33e7
Compare
When function igc_rx_hash() was introduced in v4.20 via commit 0507ef8 ("igc: Add transmit and receive fastpath and interrupt handlers"), the hardware wasn't configured to provide RSS hash, thus it made sense to not enable net_device NETIF_F_RXHASH feature bit. The NIC hardware was configured to enable RSS hash info in v5.2 via commit 2121c27 ("igc: Add multiple receive queues control supporting"), but forgot to set the NETIF_F_RXHASH feature bit. The original implementation of igc_rx_hash() didn't extract the associated pkt_hash_type, but statically set PKT_HASH_TYPE_L3. The largest portions of this patch are about extracting the RSS Type from the hardware and mapping this to enum pkt_hash_types. This was based on Foxville i225 software user manual rev-1.3.1 and tested on Intel Ethernet Controller I225-LM (rev 03). For UDP it's worth noting that RSS (type) hashing have been disabled both for IPv4 and IPv6 (see IGC_MRQC_RSS_FIELD_IPV4_UDP + IGC_MRQC_RSS_FIELD_IPV6_UDP) because hardware RSS doesn't handle fragmented pkts well when enabled (can cause out-of-order). This results in PKT_HASH_TYPE_L3 for UDP packets, and hash value doesn't include UDP port numbers. Not being PKT_HASH_TYPE_L4, have the effect that netstack will do a software based hash calc calling into flow_dissect, but only when code calls skb_get_hash(), which doesn't necessary happen for local delivery. Fixes: 2121c27 ("igc: Add multiple receive queues control supporting") Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
To correlate the hardware RX timestamp with something, add tracking of two software timestamps both clock source CLOCK_TAI (see description in man clock_gettime(2)). XDP metadata is extended with xdp_timestamp for capturing when XDP received the packet. Populated with BPF helper bpf_ktime_get_tai_ns(). I could not find a BPF helper for getting CLOCK_REALTIME, which would have been preferred. In userspace when AF_XDP sees the packet another software timestamp is recorded via clock_gettime() also clock source CLOCK_TAI. Example output shortly after loading igc driver: poll: 1 (0) xsk_ring_cons__peek: 1 0x11fc958: rx_desc[7]->addr=10000000000f000 addr=f100 comp_addr=f000 rx_hash: 0x00000000 rx_timestamp: 1676297171760293047 (sec:1676297171.7603) XDP RX-time: 1676297208760355863 (sec:1676297208.7604) delta sec:37.0001 AF_XDP time: 1676297208760416292 (sec:1676297208.7604) delta sec:0.0001 (60.429 usec) 0x11fc958: complete idx=15 addr=f000 The first observation is that the 37 sec difference between RX HW vs XDP timestamps, which indicate hardware is likely clock source CLOCK_REALTIME, because (as of this writing) CLOCK_TAI is initialised with a 37 sec offset. The 60 usec (microsec) difference between XDP vs AF_XDP userspace is the userspace wakeup time. On this hardware it was caused by CPU idle sleep states, which can be reduced by tuning /dev/cpu_dma_latency. View current requested/allowed latency bound via: hexdump --format '"%d\n"' /dev/cpu_dma_latency More explanation of the output and how this can be used to identify clock drift for the HW clock can be seen here[1]: [1] https://github.com/xdp-project/xdp-project/blob/master/areas/hints/xdp_hints_kfuncs02_driver_igc.org Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Acked-by: Stanislav Fomichev <sdf@google.com>
When driver developers add XDP-hints kfuncs for RX hash it is practical to print the return code in bpf_printk trace pipe log. Print hash value as a hex value, both AF_XDP userspace and bpf_prog, as this makes it easier to spot poor quality hashes. Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Acked-by: Stanislav Fomichev <sdf@google.com>
|
Upstream branch: d9d93f3 |
Driver specific metadata data for XDP-hints kfuncs are propagated via tail extending the struct xdp_buff with a locally scoped driver struct. Zero-Copy AF_XDP/XSK does similar tricks via struct xdp_buff_xsk. This xdp_buff_xsk struct contains a CB area (24 bytes) that can be used for extending the locally scoped driver into. The XSK_CHECK_PRIV_TYPE define catch size violations build time. Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
The NIC hardware RX timestamping mechanism adds an optional tailored header before the MAC header containing packet reception time. Optional depending on RX descriptor TSIP status bit (IGC_RXDADV_STAT_TSIP). In case this bit is set driver does offset adjustments to packet data start and extracts the timestamp. The timestamp need to be extracted before invoking the XDP bpf_prog, because this area just before the packet is also accessible by XDP via data_meta context pointer (and helper bpf_xdp_adjust_meta). Thus, an XDP bpf_prog can potentially overwrite this and corrupt data that we want to extract with the new kfunc for reading the timestamp. Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
This implements XDP hints kfunc for RX-hash (xmo_rx_hash) straightforward by returning the u32 hash value. The associated RSS-type for the hash value isn't available to the BPF-prog caller. This is problematic if BPF-prog tries to do L4 load-balancing with the hardware hash, but the RSS hash type is L3 based. For this driver this issue occurs for UDP packets, as driver (default config) does L3 hashing for UDP packets (excludes UDP src/dest ports in hash calc). Tested that the igc_rss_type_num for UDP is either IGC_RSS_TYPE_HASH_IPV4 or IGC_RSS_TYPE_HASH_IPV6. Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
kernel-patches-bot
force-pushed
the
series/731202=>bpf-next
branch
from
4de348e
to
03166f7
Compare
|
At least one diff in series https://patchwork.kernel.org/project/netdevbpf/list/?series=732805 expired. Closing PR. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull request for series with
subject: XDP-hints kfuncs for Intel driver igc
version: 2
url: https://patchwork.kernel.org/project/netdevbpf/list/?series=732345