2018-03-20 07:58:10 -07:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
|
|
|
/* Copyright (c) 2018, Intel Corporation. */
|
|
|
|
|
|
|
|
#ifndef _ICE_TXRX_H_
|
|
|
|
#define _ICE_TXRX_H_
|
|
|
|
|
2019-11-04 09:38:56 -08:00
|
|
|
#include "ice_type.h"
|
|
|
|
|
2018-03-20 07:58:10 -07:00
|
|
|
#define ICE_DFLT_IRQ_WORK 256
|
2019-10-24 01:11:22 -07:00
|
|
|
#define ICE_RXBUF_3072 3072
|
2018-03-20 07:58:13 -07:00
|
|
|
#define ICE_RXBUF_2048 2048
|
2023-01-31 21:44:54 +01:00
|
|
|
#define ICE_RXBUF_1664 1664
|
2019-10-24 01:11:22 -07:00
|
|
|
#define ICE_RXBUF_1536 1536
|
2018-03-20 07:58:13 -07:00
|
|
|
#define ICE_MAX_CHAINED_RX_BUFS 5
|
2018-03-20 07:58:14 -07:00
|
|
|
#define ICE_MAX_BUF_TXD 8
|
|
|
|
#define ICE_MIN_TX_LEN 17
|
2023-01-31 21:44:54 +01:00
|
|
|
#define ICE_MAX_FRAME_LEGACY_RX 8320
|
2018-03-20 07:58:14 -07:00
|
|
|
|
|
|
|
/* The size limit for a transmit buffer in a descriptor is (16K - 1).
|
|
|
|
* In order to align with the read requests we will align the value to
|
|
|
|
* the nearest 4K which represents our maximum read request size.
|
|
|
|
*/
|
|
|
|
#define ICE_MAX_READ_REQ_SIZE 4096
|
|
|
|
#define ICE_MAX_DATA_PER_TXD (16 * 1024 - 1)
|
|
|
|
#define ICE_MAX_DATA_PER_TXD_ALIGNED \
|
|
|
|
(~(ICE_MAX_READ_REQ_SIZE - 1) & ICE_MAX_DATA_PER_TXD)
|
|
|
|
|
2018-03-20 07:58:13 -07:00
|
|
|
#define ICE_MAX_TXQ_PER_TXQG 128
|
|
|
|
|
2019-10-24 01:11:23 -07:00
|
|
|
/* Attempt to maximize the headroom available for incoming frames. We use a 2K
|
|
|
|
* buffer for MTUs <= 1500 and need 1536/1534 to store the data for the frame.
|
|
|
|
* This leaves us with 512 bytes of room. From that we need to deduct the
|
|
|
|
* space needed for the shared info and the padding needed to IP align the
|
|
|
|
* frame.
|
|
|
|
*
|
|
|
|
* Note: For cache line sizes 256 or larger this value is going to end
|
2020-02-06 01:20:13 -08:00
|
|
|
* up negative. In these cases we should fall back to the legacy
|
|
|
|
* receive path.
|
2019-10-24 01:11:23 -07:00
|
|
|
*/
|
|
|
|
#if (PAGE_SIZE < 8192)
|
|
|
|
#define ICE_2K_TOO_SMALL_WITH_PADDING \
|
2020-05-15 17:36:38 -07:00
|
|
|
((unsigned int)(NET_SKB_PAD + ICE_RXBUF_1536) > \
|
|
|
|
SKB_WITH_OVERHEAD(ICE_RXBUF_2048))
|
2019-10-24 01:11:23 -07:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_compute_pad - compute the padding
|
2020-09-25 15:24:37 -07:00
|
|
|
* @rx_buf_len: buffer length
|
2019-10-24 01:11:23 -07:00
|
|
|
*
|
|
|
|
* Figure out the size of half page based on given buffer length and
|
|
|
|
* then subtract the skb_shared_info followed by subtraction of the
|
|
|
|
* actual buffer length; this in turn results in the actual space that
|
|
|
|
* is left for padding usage
|
|
|
|
*/
|
|
|
|
static inline int ice_compute_pad(int rx_buf_len)
|
|
|
|
{
|
|
|
|
int half_page_size;
|
|
|
|
|
|
|
|
half_page_size = ALIGN(rx_buf_len, PAGE_SIZE / 2);
|
|
|
|
return SKB_WITH_OVERHEAD(half_page_size) - rx_buf_len;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ice_skb_pad - determine the padding that we can supply
|
|
|
|
*
|
|
|
|
* Figure out the right Rx buffer size and based on that calculate the
|
|
|
|
* padding
|
|
|
|
*/
|
|
|
|
static inline int ice_skb_pad(void)
|
|
|
|
{
|
|
|
|
int rx_buf_len;
|
|
|
|
|
|
|
|
/* If a 2K buffer cannot handle a standard Ethernet frame then
|
|
|
|
* optimize padding for a 3K buffer instead of a 1.5K buffer.
|
|
|
|
*
|
|
|
|
* For a 3K buffer we need to add enough padding to allow for
|
|
|
|
* tailroom due to NET_IP_ALIGN possibly shifting us out of
|
|
|
|
* cache-line alignment.
|
|
|
|
*/
|
|
|
|
if (ICE_2K_TOO_SMALL_WITH_PADDING)
|
|
|
|
rx_buf_len = ICE_RXBUF_3072 + SKB_DATA_ALIGN(NET_IP_ALIGN);
|
|
|
|
else
|
|
|
|
rx_buf_len = ICE_RXBUF_1536;
|
|
|
|
|
|
|
|
/* if needed make room for NET_IP_ALIGN */
|
|
|
|
rx_buf_len -= NET_IP_ALIGN;
|
|
|
|
|
|
|
|
return ice_compute_pad(rx_buf_len);
|
|
|
|
}
|
|
|
|
|
|
|
|
#define ICE_SKB_PAD ice_skb_pad()
|
|
|
|
#else
|
|
|
|
#define ICE_2K_TOO_SMALL_WITH_PADDING false
|
|
|
|
#define ICE_SKB_PAD (NET_SKB_PAD + NET_IP_ALIGN)
|
|
|
|
#endif
|
|
|
|
|
ice: Fix tx_timeout in PF driver
Prior to this commit the driver was running into tx_timeouts when a
queue was stressed enough. This was happening because the HW tail
and SW tail (NTU) were incorrectly out of sync. Consequently this was
causing the HW head to collide with the HW tail, which to the hardware
means that all descriptors posted for Tx have been processed.
Due to the Tx logic used in the driver SW tail and HW tail are allowed
to be out of sync. This is done as an optimization because it allows the
driver to write HW tail as infrequently as possible, while still
updating the SW tail index to keep track. However, there are situations
where this results in the tail never getting updated, resulting in Tx
timeouts.
Tx HW tail write condition:
if (netif_xmit_stopped(txring_txq(tx_ring) || !skb->xmit_more)
writel(sw_tail, tx_ring->tail);
An issue was found in the Tx logic that was causing the afore mentioned
condition for updating HW tail to never happen, causing tx_timeouts.
In ice_xmit_frame_ring we calculate how many descriptors we need for the
Tx transaction based on the skb the kernel hands us. This is then passed
into ice_maybe_stop_tx along with some extra padding to determine if we
have enough descriptors available for this transaction. If we don't then
we return -EBUSY to the stack, otherwise we move on and eventually
prepare the Tx descriptors accordingly in ice_tx_map and set
next_to_watch. In ice_tx_map we make another call to ice_maybe_stop_tx
with a value of MAX_SKB_FRAGS + 4. The key here is that this value is
possibly less than the value we sent in the first call to
ice_maybe_stop_tx in ice_xmit_frame_ring. Now, if the number of unused
descriptors is between MAX_SKB_FRAGS + 4 and the value used in the first
call to ice_maybe_stop_tx in ice_xmit_frame_ring then we do not update
the HW tail because of the "Tx HW tail write condition" above. This is
because in ice_maybe_stop_tx we return success from ice_maybe_stop_tx
instead of calling __ice_maybe_stop_tx and subsequently calling
netif_stop_subqueue, which sets the __QUEUE_STATE_DEV_XOFF bit. This
bit is then checked in the "Tx HW tail write condition" by calling
netif_xmit_stopped and subsequently updating HW tail if the
afore mentioned bit is set.
In ice_clean_tx_irq, if next_to_watch is not NULL, we end up cleaning
the descriptors that HW sets the DD bit on and we have the budget. The
HW head will eventually run into the HW tail in response to the
description in the paragraph above.
The next time through ice_xmit_frame_ring we make the initial call to
ice_maybe_stop_tx with another skb from the stack. This time we do not
have enough descriptors available and we return NETDEV_TX_BUSY to the
stack and end up setting next_to_watch to NULL.
This is where we are stuck. In ice_clean_tx_irq we never clean anything
because next_to_watch is always NULL and in ice_xmit_frame_ring we never
update HW tail because we already return NETDEV_TX_BUSY to the stack and
eventually we hit a tx_timeout.
This issue was fixed by making sure that the second call to
ice_maybe_stop_tx in ice_tx_map is passed a value that is >= the value
that was used on the initial call to ice_maybe_stop_tx in
ice_xmit_frame_ring. This was done by adding the following defines to
make the logic more clear and to reduce the chance of mucking this up
again:
ICE_CACHE_LINE_BYTES 64
ICE_DESCS_PER_CACHE_LINE (ICE_CACHE_LINE_BYTES / \
sizeof(struct ice_tx_desc))
ICE_DESCS_FOR_CTX_DESC 1
ICE_DESCS_FOR_SKB_DATA_PTR 1
The ICE_CACHE_LINE_BYTES being 64 is an assumption being made so we
don't have to figure this out on every pass through the Tx path. Instead
I added a sanity check in ice_probe to verify cache line size and print
a message if it's not 64 Bytes. This will make it easier to file issues
if they are seen when the cache line size is not 64 Bytes when reading
from the GLPCI_CNF2 register.
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2018-10-26 10:40:58 -07:00
|
|
|
/* We are assuming that the cache line is always 64 Bytes here for ice.
|
|
|
|
* In order to make sure that is a correct assumption there is a check in probe
|
|
|
|
* to print a warning if the read from GLPCI_CNF2 tells us that the cache line
|
|
|
|
* size is 128 bytes. We do it this way because we do not want to read the
|
|
|
|
* GLPCI_CNF2 register or a variable containing the value on every pass through
|
|
|
|
* the Tx path.
|
|
|
|
*/
|
|
|
|
#define ICE_CACHE_LINE_BYTES 64
|
|
|
|
#define ICE_DESCS_PER_CACHE_LINE (ICE_CACHE_LINE_BYTES / \
|
|
|
|
sizeof(struct ice_tx_desc))
|
|
|
|
#define ICE_DESCS_FOR_CTX_DESC 1
|
|
|
|
#define ICE_DESCS_FOR_SKB_DATA_PTR 1
|
|
|
|
/* Tx descriptors needed, worst case */
|
|
|
|
#define DESC_NEEDED (MAX_SKB_FRAGS + ICE_DESCS_FOR_CTX_DESC + \
|
|
|
|
ICE_DESCS_PER_CACHE_LINE + ICE_DESCS_FOR_SKB_DATA_PTR)
|
2018-03-20 07:58:13 -07:00
|
|
|
#define ICE_DESC_UNUSED(R) \
|
2020-05-15 17:36:38 -07:00
|
|
|
(u16)((((R)->next_to_clean > (R)->next_to_use) ? 0 : (R)->count) + \
|
|
|
|
(R)->next_to_clean - (R)->next_to_use - 1)
|
2018-03-20 07:58:13 -07:00
|
|
|
|
ice: Add support for XDP multi-buffer on Rx side
Ice driver needs to be a bit reworked on Rx data path in order to
support multi-buffer XDP. For skb path, it currently works in a way that
Rx ring carries pointer to skb so if driver didn't manage to combine
fragmented frame at current NAPI instance, it can restore the state on
next instance and keep looking for last fragment (so descriptor with EOP
bit set). What needs to be achieved is that xdp_buff needs to be
combined in such way (linear + frags part) in the first place. Then skb
will be ready to go in case of XDP_PASS or BPF program being not present
on interface. If BPF program is there, it would work on multi-buffer
XDP. At this point xdp_buff resides directly on Rx ring, so given the
fact that skb will be built straight from xdp_buff, there will be no
further need to carry skb on Rx ring.
Besides removing skb pointer from Rx ring, lots of members have been
moved around within ice_rx_ring. First and foremost reason was to place
rx_buf with xdp_buff on the same cacheline. This means that once we
touch rx_buf (which is a preceding step before touching xdp_buff),
xdp_buff will already be hot in cache. Second thing was that xdp_rxq is
used rather rarely and it occupies a separate cacheline, so maybe it is
better to have it at the end of ice_rx_ring.
Other change that affects ice_rx_ring is the introduction of
ice_rx_ring::first_desc. Its purpose is twofold - first is to propagate
rx_buf->act to all the parts of current xdp_buff after running XDP
program, so that ice_put_rx_buf() that got moved out of the main Rx
processing loop will be able to tak an appriopriate action on each
buffer. Second is for ice_construct_skb().
ice_construct_skb() has a copybreak mechanism which had an explicit
impact on xdp_buff->skb conversion in the new approach when legacy Rx
flag is toggled. It works in a way that linear part is 256 bytes long,
if frame is bigger than that, remaining bytes are going as a frag to
skb_shared_info.
This means while memcpying frags from xdp_buff to newly allocated skb,
care needs to be taken when picking the destination frag array entry.
Upon the time ice_construct_skb() is called, when dealing with
fragmented frame, current rx_buf points to the *last* fragment, but
copybreak needs to be done against the first one. That's where
ice_rx_ring::first_desc helps.
When frame building spans across NAPI polls (DD bit is not set on
current descriptor and xdp->data is not NULL) with current Rx buffer
handling state there might be some problems.
Since calls to ice_put_rx_buf() were pulled out of the main Rx
processing loop and were scoped from cached_ntc to current ntc, remember
that now mentioned function relies on rx_buf->act, which is set within
ice_run_xdp(). ice_run_xdp() is called when EOP bit was found, so
currently we could put Rx buffer with rx_buf->act being *uninitialized*.
To address this, change scoping to rely on first_desc on both boundaries
instead.
This also implies that cleaned_count which is used as an input to
ice_alloc_rx_buffers() and tells how many new buffers should be refilled
has to be adjusted. If it stayed as is, what could happen is a case
where ntc would go over ntu.
Therefore, remove cleaned_count altogether and use against allocing
routine newly introduced ICE_RX_DESC_UNUSED() macro which is an
equivalent of ICE_DESC_UNUSED() dedicated for Rx side and based on
struct ice_rx_ring::first_desc instead of next_to_clean.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Link: https://lore.kernel.org/bpf/20230131204506.219292-11-maciej.fijalkowski@intel.com
2023-01-31 21:45:03 +01:00
|
|
|
#define ICE_RX_DESC_UNUSED(R) \
|
|
|
|
((((R)->first_desc > (R)->next_to_use) ? 0 : (R)->count) + \
|
|
|
|
(R)->first_desc - (R)->next_to_use - 1)
|
|
|
|
|
2022-01-25 17:04:41 +01:00
|
|
|
#define ICE_RING_QUARTER(R) ((R)->count >> 2)
|
|
|
|
|
2018-03-20 07:58:15 -07:00
|
|
|
#define ICE_TX_FLAGS_TSO BIT(0)
|
|
|
|
#define ICE_TX_FLAGS_HW_VLAN BIT(1)
|
|
|
|
#define ICE_TX_FLAGS_SW_VLAN BIT(2)
|
ice: Robustify cleaning/completing XDP Tx buffers
When queueing frames from a Page Pool for redirecting to a device backed
by the ice driver, `perf top` shows heavy load on page_alloc() and
page_frag_free(), despite that on a properly working system it must be
fully or at least almost zero-alloc. The problem is in fact a bit deeper
and raises from how ice cleans up completed Tx buffers.
The story so far: when cleaning/freeing the resources related to
a particular completed Tx frame (skbs, DMA mappings etc.), ice uses some
heuristics only without setting any type explicitly (except for dummy
Flow Director packets, which are marked via ice_tx_buf::tx_flags).
This kinda works, but only up to some point. For example, currently ice
assumes that each frame coming to __ice_xmit_xdp_ring(), is backed by
either plain order-0 page or plain page frag, while it may also be
backed by Page Pool or any other possible memory models introduced in
future. This means any &xdp_frame must be freed properly via
xdp_return_frame() family with no assumptions.
In order to do that, the whole heuristics must be replaced with setting
the Tx buffer/frame type explicitly, just how it's always been done via
an enum. Let us reuse 16 bits from ::tx_flags -- 1 bit-and instr won't
hurt much -- especially given that sometimes there was a check for
%ICE_TX_FLAGS_DUMMY_PKT, which is now turned from a flag to an enum
member. The rest of the changes is straightforward and most of it is
just a conversion to rely now on the type set in &ice_tx_buf rather than
to some secondary properties.
For now, no functional changes intended, the change only prepares the
ground for starting freeing XDP frames properly next step. And it must
be done atomically/synchronously to not break stuff.
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/bpf/20230210170618.1973430-5-alexandr.lobakin@intel.com
2023-02-10 18:06:16 +01:00
|
|
|
/* Free, was ICE_TX_FLAGS_DUMMY_PKT */
|
ice: enable transmit timestamps for E810 devices
Add support for enabling Tx timestamp requests for outgoing packets on
E810 devices.
The ice hardware can support multiple outstanding Tx timestamp requests.
When sending a descriptor to hardware, a Tx timestamp request is made by
setting a request bit, and assigning an index that represents which Tx
timestamp index to store the timestamp in.
Hardware makes no effort to synchronize the index use, so it is up to
software to ensure that Tx timestamp indexes are not re-used before the
timestamp is reported back.
To do this, introduce a Tx timestamp tracker which will keep track of
currently in-use indexes.
In the hot path, if a packet has a timestamp request, an index will be
requested from the tracker. Unfortunately, this does require a lock as
the indexes are shared across all queues on a PHY. There are not enough
indexes to reliably assign only 1 to each queue.
For the E810 devices, the timestamp indexes are not shared across PHYs,
so each port can have its own tracking.
Once hardware captures a timestamp, an interrupt is fired. In this
interrupt, trigger a new work item that will figure out which timestamp
was completed, and report the timestamp back to the stack.
This function loops through the Tx timestamp indexes and checks whether
there is now a valid timestamp. If so, it clears the PHY timestamp
indication in the PHY memory, locks and removes the SKB and bit in the
tracker, then reports the timestamp to the stack.
It is possible in some cases that a timestamp request will be initiated
but never completed. This might occur if the packet is dropped by
software or hardware before it reaches the PHY.
Add a task to the periodic work function that will check whether
a timestamp request is more than a few seconds old. If so, the timestamp
index is cleared in the PHY, and the SKB is released.
Just as with Rx timestamps, the Tx timestamps are only 40 bits wide, and
use the same overall logic for extending to 64 bits of nanoseconds.
With this change, E810 devices should be able to perform basic PTP
functionality.
Future changes will extend the support to cover the E822-based devices.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-06-09 09:39:53 -07:00
|
|
|
#define ICE_TX_FLAGS_TSYN BIT(4)
|
2020-05-06 09:32:30 -07:00
|
|
|
#define ICE_TX_FLAGS_IPV4 BIT(5)
|
|
|
|
#define ICE_TX_FLAGS_IPV6 BIT(6)
|
|
|
|
#define ICE_TX_FLAGS_TUNNEL BIT(7)
|
ice: Add hot path support for 802.1Q and 802.1ad VLAN offloads
Currently the driver only supports 802.1Q VLAN insertion and stripping.
However, once Double VLAN Mode (DVM) is fully supported, then both 802.1Q
and 802.1ad VLAN insertion and stripping will be supported. Unfortunately
the VSI context parameters only allow for one VLAN ethertype at a time
for VLAN offloads so only one or the other VLAN ethertype offload can be
supported at once.
To support this, multiple changes are needed.
Rx path changes:
[1] In DVM, the Rx queue context l2tagsel field needs to be cleared so
the outermost tag shows up in the l2tag2_2nd field of the Rx flex
descriptor. In Single VLAN Mode (SVM), the l2tagsel field should remain
1 to support SVM configurations.
[2] Modify the ice_test_staterr() function to take a __le16 instead of
the ice_32b_rx_flex_desc union pointer so this function can be used for
both rx_desc->wb.status_error0 and rx_desc->wb.status_error1.
[3] Add the new inline function ice_get_vlan_tag_from_rx_desc() that
checks if there is a VLAN tag in l2tag1 or l2tag2_2nd.
[4] In ice_receive_skb(), add a check to see if NETIF_F_HW_VLAN_STAG_RX
is enabled in netdev->features. If it is, then this is the VLAN
ethertype that needs to be added to the stripping VLAN tag. Since
ice_fix_features() prevents CTAG_RX and STAG_RX from being enabled
simultaneously, the VLAN ethertype will only ever be 802.1Q or 802.1ad.
Tx path changes:
[1] In DVM, the VLAN tag needs to be placed in the l2tag2 field of the Tx
context descriptor. The new define ICE_TX_FLAGS_HW_OUTER_SINGLE_VLAN was
added to the list of tx_flags to handle this case.
[2] When the stack requests the VLAN tag to be offloaded on Tx, the
driver needs to set either ICE_TX_FLAGS_HW_OUTER_SINGLE_VLAN or
ICE_TX_FLAGS_HW_VLAN, so the tag is inserted in l2tag2 or l2tag1
respectively. To determine which location to use, set a bit in the Tx
ring flags field during ring allocation that can be used to determine
which field to use in the Tx descriptor. In DVM, always use l2tag2,
and in SVM, always use l2tag1.
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-12-02 08:38:47 -08:00
|
|
|
#define ICE_TX_FLAGS_HW_OUTER_SINGLE_VLAN BIT(8)
|
2018-03-20 07:58:15 -07:00
|
|
|
|
2019-11-04 09:38:56 -08:00
|
|
|
#define ICE_XDP_PASS 0
|
|
|
|
#define ICE_XDP_CONSUMED BIT(0)
|
|
|
|
#define ICE_XDP_TX BIT(1)
|
|
|
|
#define ICE_XDP_REDIR BIT(2)
|
2022-04-13 17:30:06 +02:00
|
|
|
#define ICE_XDP_EXIT BIT(3)
|
ice: Add support for XDP multi-buffer on Rx side
Ice driver needs to be a bit reworked on Rx data path in order to
support multi-buffer XDP. For skb path, it currently works in a way that
Rx ring carries pointer to skb so if driver didn't manage to combine
fragmented frame at current NAPI instance, it can restore the state on
next instance and keep looking for last fragment (so descriptor with EOP
bit set). What needs to be achieved is that xdp_buff needs to be
combined in such way (linear + frags part) in the first place. Then skb
will be ready to go in case of XDP_PASS or BPF program being not present
on interface. If BPF program is there, it would work on multi-buffer
XDP. At this point xdp_buff resides directly on Rx ring, so given the
fact that skb will be built straight from xdp_buff, there will be no
further need to carry skb on Rx ring.
Besides removing skb pointer from Rx ring, lots of members have been
moved around within ice_rx_ring. First and foremost reason was to place
rx_buf with xdp_buff on the same cacheline. This means that once we
touch rx_buf (which is a preceding step before touching xdp_buff),
xdp_buff will already be hot in cache. Second thing was that xdp_rxq is
used rather rarely and it occupies a separate cacheline, so maybe it is
better to have it at the end of ice_rx_ring.
Other change that affects ice_rx_ring is the introduction of
ice_rx_ring::first_desc. Its purpose is twofold - first is to propagate
rx_buf->act to all the parts of current xdp_buff after running XDP
program, so that ice_put_rx_buf() that got moved out of the main Rx
processing loop will be able to tak an appriopriate action on each
buffer. Second is for ice_construct_skb().
ice_construct_skb() has a copybreak mechanism which had an explicit
impact on xdp_buff->skb conversion in the new approach when legacy Rx
flag is toggled. It works in a way that linear part is 256 bytes long,
if frame is bigger than that, remaining bytes are going as a frag to
skb_shared_info.
This means while memcpying frags from xdp_buff to newly allocated skb,
care needs to be taken when picking the destination frag array entry.
Upon the time ice_construct_skb() is called, when dealing with
fragmented frame, current rx_buf points to the *last* fragment, but
copybreak needs to be done against the first one. That's where
ice_rx_ring::first_desc helps.
When frame building spans across NAPI polls (DD bit is not set on
current descriptor and xdp->data is not NULL) with current Rx buffer
handling state there might be some problems.
Since calls to ice_put_rx_buf() were pulled out of the main Rx
processing loop and were scoped from cached_ntc to current ntc, remember
that now mentioned function relies on rx_buf->act, which is set within
ice_run_xdp(). ice_run_xdp() is called when EOP bit was found, so
currently we could put Rx buffer with rx_buf->act being *uninitialized*.
To address this, change scoping to rely on first_desc on both boundaries
instead.
This also implies that cleaned_count which is used as an input to
ice_alloc_rx_buffers() and tells how many new buffers should be refilled
has to be adjusted. If it stayed as is, what could happen is a case
where ntc would go over ntu.
Therefore, remove cleaned_count altogether and use against allocing
routine newly introduced ICE_RX_DESC_UNUSED() macro which is an
equivalent of ICE_DESC_UNUSED() dedicated for Rx side and based on
struct ice_rx_ring::first_desc instead of next_to_clean.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Link: https://lore.kernel.org/bpf/20230131204506.219292-11-maciej.fijalkowski@intel.com
2023-01-31 21:45:03 +01:00
|
|
|
#define ICE_SKB_CONSUMED ICE_XDP_CONSUMED
|
2019-11-04 09:38:56 -08:00
|
|
|
|
2019-02-13 10:51:07 -08:00
|
|
|
#define ICE_RX_DMA_ATTR \
|
|
|
|
(DMA_ATTR_SKIP_CPU_SYNC | DMA_ATTR_WEAK_ORDERING)
|
|
|
|
|
2019-11-04 09:38:56 -08:00
|
|
|
#define ICE_ETH_PKT_HDR_PAD (ETH_HLEN + ETH_FCS_LEN + (VLAN_HLEN * 2))
|
|
|
|
|
|
|
|
#define ICE_TXD_LAST_DESC_CMD (ICE_TX_DESC_CMD_EOP | ICE_TX_DESC_CMD_RS)
|
|
|
|
|
ice: Robustify cleaning/completing XDP Tx buffers
When queueing frames from a Page Pool for redirecting to a device backed
by the ice driver, `perf top` shows heavy load on page_alloc() and
page_frag_free(), despite that on a properly working system it must be
fully or at least almost zero-alloc. The problem is in fact a bit deeper
and raises from how ice cleans up completed Tx buffers.
The story so far: when cleaning/freeing the resources related to
a particular completed Tx frame (skbs, DMA mappings etc.), ice uses some
heuristics only without setting any type explicitly (except for dummy
Flow Director packets, which are marked via ice_tx_buf::tx_flags).
This kinda works, but only up to some point. For example, currently ice
assumes that each frame coming to __ice_xmit_xdp_ring(), is backed by
either plain order-0 page or plain page frag, while it may also be
backed by Page Pool or any other possible memory models introduced in
future. This means any &xdp_frame must be freed properly via
xdp_return_frame() family with no assumptions.
In order to do that, the whole heuristics must be replaced with setting
the Tx buffer/frame type explicitly, just how it's always been done via
an enum. Let us reuse 16 bits from ::tx_flags -- 1 bit-and instr won't
hurt much -- especially given that sometimes there was a check for
%ICE_TX_FLAGS_DUMMY_PKT, which is now turned from a flag to an enum
member. The rest of the changes is straightforward and most of it is
just a conversion to rely now on the type set in &ice_tx_buf rather than
to some secondary properties.
For now, no functional changes intended, the change only prepares the
ground for starting freeing XDP frames properly next step. And it must
be done atomically/synchronously to not break stuff.
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/bpf/20230210170618.1973430-5-alexandr.lobakin@intel.com
2023-02-10 18:06:16 +01:00
|
|
|
/**
|
|
|
|
* enum ice_tx_buf_type - type of &ice_tx_buf to act on Tx completion
|
|
|
|
* @ICE_TX_BUF_EMPTY: unused OR XSk frame, no action required
|
|
|
|
* @ICE_TX_BUF_DUMMY: dummy Flow Director packet, unmap and kfree()
|
|
|
|
* @ICE_TX_BUF_FRAG: mapped skb OR &xdp_buff frag, only unmap DMA
|
|
|
|
* @ICE_TX_BUF_SKB: &sk_buff, unmap and consume_skb(), update stats
|
|
|
|
* @ICE_TX_BUF_XDP_TX: &xdp_buff, unmap and page_frag_free(), stats
|
2023-02-10 18:06:17 +01:00
|
|
|
* @ICE_TX_BUF_XDP_XMIT: &xdp_frame, unmap and xdp_return_frame(), stats
|
ice: Robustify cleaning/completing XDP Tx buffers
When queueing frames from a Page Pool for redirecting to a device backed
by the ice driver, `perf top` shows heavy load on page_alloc() and
page_frag_free(), despite that on a properly working system it must be
fully or at least almost zero-alloc. The problem is in fact a bit deeper
and raises from how ice cleans up completed Tx buffers.
The story so far: when cleaning/freeing the resources related to
a particular completed Tx frame (skbs, DMA mappings etc.), ice uses some
heuristics only without setting any type explicitly (except for dummy
Flow Director packets, which are marked via ice_tx_buf::tx_flags).
This kinda works, but only up to some point. For example, currently ice
assumes that each frame coming to __ice_xmit_xdp_ring(), is backed by
either plain order-0 page or plain page frag, while it may also be
backed by Page Pool or any other possible memory models introduced in
future. This means any &xdp_frame must be freed properly via
xdp_return_frame() family with no assumptions.
In order to do that, the whole heuristics must be replaced with setting
the Tx buffer/frame type explicitly, just how it's always been done via
an enum. Let us reuse 16 bits from ::tx_flags -- 1 bit-and instr won't
hurt much -- especially given that sometimes there was a check for
%ICE_TX_FLAGS_DUMMY_PKT, which is now turned from a flag to an enum
member. The rest of the changes is straightforward and most of it is
just a conversion to rely now on the type set in &ice_tx_buf rather than
to some secondary properties.
For now, no functional changes intended, the change only prepares the
ground for starting freeing XDP frames properly next step. And it must
be done atomically/synchronously to not break stuff.
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/bpf/20230210170618.1973430-5-alexandr.lobakin@intel.com
2023-02-10 18:06:16 +01:00
|
|
|
* @ICE_TX_BUF_XSK_TX: &xdp_buff on XSk queue, xsk_buff_free(), stats
|
|
|
|
*/
|
|
|
|
enum ice_tx_buf_type {
|
|
|
|
ICE_TX_BUF_EMPTY = 0U,
|
|
|
|
ICE_TX_BUF_DUMMY,
|
|
|
|
ICE_TX_BUF_FRAG,
|
|
|
|
ICE_TX_BUF_SKB,
|
|
|
|
ICE_TX_BUF_XDP_TX,
|
2023-02-10 18:06:17 +01:00
|
|
|
ICE_TX_BUF_XDP_XMIT,
|
ice: Robustify cleaning/completing XDP Tx buffers
When queueing frames from a Page Pool for redirecting to a device backed
by the ice driver, `perf top` shows heavy load on page_alloc() and
page_frag_free(), despite that on a properly working system it must be
fully or at least almost zero-alloc. The problem is in fact a bit deeper
and raises from how ice cleans up completed Tx buffers.
The story so far: when cleaning/freeing the resources related to
a particular completed Tx frame (skbs, DMA mappings etc.), ice uses some
heuristics only without setting any type explicitly (except for dummy
Flow Director packets, which are marked via ice_tx_buf::tx_flags).
This kinda works, but only up to some point. For example, currently ice
assumes that each frame coming to __ice_xmit_xdp_ring(), is backed by
either plain order-0 page or plain page frag, while it may also be
backed by Page Pool or any other possible memory models introduced in
future. This means any &xdp_frame must be freed properly via
xdp_return_frame() family with no assumptions.
In order to do that, the whole heuristics must be replaced with setting
the Tx buffer/frame type explicitly, just how it's always been done via
an enum. Let us reuse 16 bits from ::tx_flags -- 1 bit-and instr won't
hurt much -- especially given that sometimes there was a check for
%ICE_TX_FLAGS_DUMMY_PKT, which is now turned from a flag to an enum
member. The rest of the changes is straightforward and most of it is
just a conversion to rely now on the type set in &ice_tx_buf rather than
to some secondary properties.
For now, no functional changes intended, the change only prepares the
ground for starting freeing XDP frames properly next step. And it must
be done atomically/synchronously to not break stuff.
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/bpf/20230210170618.1973430-5-alexandr.lobakin@intel.com
2023-02-10 18:06:16 +01:00
|
|
|
ICE_TX_BUF_XSK_TX,
|
|
|
|
};
|
|
|
|
|
2018-03-20 07:58:13 -07:00
|
|
|
struct ice_tx_buf {
|
2023-01-31 21:45:04 +01:00
|
|
|
union {
|
|
|
|
struct ice_tx_desc *next_to_watch;
|
|
|
|
u32 rs_idx;
|
|
|
|
};
|
2019-11-04 09:38:56 -08:00
|
|
|
union {
|
ice: Robustify cleaning/completing XDP Tx buffers
When queueing frames from a Page Pool for redirecting to a device backed
by the ice driver, `perf top` shows heavy load on page_alloc() and
page_frag_free(), despite that on a properly working system it must be
fully or at least almost zero-alloc. The problem is in fact a bit deeper
and raises from how ice cleans up completed Tx buffers.
The story so far: when cleaning/freeing the resources related to
a particular completed Tx frame (skbs, DMA mappings etc.), ice uses some
heuristics only without setting any type explicitly (except for dummy
Flow Director packets, which are marked via ice_tx_buf::tx_flags).
This kinda works, but only up to some point. For example, currently ice
assumes that each frame coming to __ice_xmit_xdp_ring(), is backed by
either plain order-0 page or plain page frag, while it may also be
backed by Page Pool or any other possible memory models introduced in
future. This means any &xdp_frame must be freed properly via
xdp_return_frame() family with no assumptions.
In order to do that, the whole heuristics must be replaced with setting
the Tx buffer/frame type explicitly, just how it's always been done via
an enum. Let us reuse 16 bits from ::tx_flags -- 1 bit-and instr won't
hurt much -- especially given that sometimes there was a check for
%ICE_TX_FLAGS_DUMMY_PKT, which is now turned from a flag to an enum
member. The rest of the changes is straightforward and most of it is
just a conversion to rely now on the type set in &ice_tx_buf rather than
to some secondary properties.
For now, no functional changes intended, the change only prepares the
ground for starting freeing XDP frames properly next step. And it must
be done atomically/synchronously to not break stuff.
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/bpf/20230210170618.1973430-5-alexandr.lobakin@intel.com
2023-02-10 18:06:16 +01:00
|
|
|
void *raw_buf; /* used for XDP_TX and FDir rules */
|
|
|
|
struct sk_buff *skb; /* used for .ndo_start_xmit() */
|
2023-02-10 18:06:17 +01:00
|
|
|
struct xdp_frame *xdpf; /* used for .ndo_xdp_xmit() */
|
ice: Robustify cleaning/completing XDP Tx buffers
When queueing frames from a Page Pool for redirecting to a device backed
by the ice driver, `perf top` shows heavy load on page_alloc() and
page_frag_free(), despite that on a properly working system it must be
fully or at least almost zero-alloc. The problem is in fact a bit deeper
and raises from how ice cleans up completed Tx buffers.
The story so far: when cleaning/freeing the resources related to
a particular completed Tx frame (skbs, DMA mappings etc.), ice uses some
heuristics only without setting any type explicitly (except for dummy
Flow Director packets, which are marked via ice_tx_buf::tx_flags).
This kinda works, but only up to some point. For example, currently ice
assumes that each frame coming to __ice_xmit_xdp_ring(), is backed by
either plain order-0 page or plain page frag, while it may also be
backed by Page Pool or any other possible memory models introduced in
future. This means any &xdp_frame must be freed properly via
xdp_return_frame() family with no assumptions.
In order to do that, the whole heuristics must be replaced with setting
the Tx buffer/frame type explicitly, just how it's always been done via
an enum. Let us reuse 16 bits from ::tx_flags -- 1 bit-and instr won't
hurt much -- especially given that sometimes there was a check for
%ICE_TX_FLAGS_DUMMY_PKT, which is now turned from a flag to an enum
member. The rest of the changes is straightforward and most of it is
just a conversion to rely now on the type set in &ice_tx_buf rather than
to some secondary properties.
For now, no functional changes intended, the change only prepares the
ground for starting freeing XDP frames properly next step. And it must
be done atomically/synchronously to not break stuff.
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/bpf/20230210170618.1973430-5-alexandr.lobakin@intel.com
2023-02-10 18:06:16 +01:00
|
|
|
struct xdp_buff *xdp; /* used for XDP_TX ZC */
|
2019-11-04 09:38:56 -08:00
|
|
|
};
|
2018-03-20 07:58:13 -07:00
|
|
|
unsigned int bytecount;
|
2023-01-31 21:45:04 +01:00
|
|
|
union {
|
|
|
|
unsigned int gso_segs;
|
ice: Robustify cleaning/completing XDP Tx buffers
When queueing frames from a Page Pool for redirecting to a device backed
by the ice driver, `perf top` shows heavy load on page_alloc() and
page_frag_free(), despite that on a properly working system it must be
fully or at least almost zero-alloc. The problem is in fact a bit deeper
and raises from how ice cleans up completed Tx buffers.
The story so far: when cleaning/freeing the resources related to
a particular completed Tx frame (skbs, DMA mappings etc.), ice uses some
heuristics only without setting any type explicitly (except for dummy
Flow Director packets, which are marked via ice_tx_buf::tx_flags).
This kinda works, but only up to some point. For example, currently ice
assumes that each frame coming to __ice_xmit_xdp_ring(), is backed by
either plain order-0 page or plain page frag, while it may also be
backed by Page Pool or any other possible memory models introduced in
future. This means any &xdp_frame must be freed properly via
xdp_return_frame() family with no assumptions.
In order to do that, the whole heuristics must be replaced with setting
the Tx buffer/frame type explicitly, just how it's always been done via
an enum. Let us reuse 16 bits from ::tx_flags -- 1 bit-and instr won't
hurt much -- especially given that sometimes there was a check for
%ICE_TX_FLAGS_DUMMY_PKT, which is now turned from a flag to an enum
member. The rest of the changes is straightforward and most of it is
just a conversion to rely now on the type set in &ice_tx_buf rather than
to some secondary properties.
For now, no functional changes intended, the change only prepares the
ground for starting freeing XDP frames properly next step. And it must
be done atomically/synchronously to not break stuff.
Signed-off-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://lore.kernel.org/bpf/20230210170618.1973430-5-alexandr.lobakin@intel.com
2023-02-10 18:06:16 +01:00
|
|
|
unsigned int nr_frags; /* used for mbuf XDP */
|
2023-01-31 21:45:04 +01:00
|
|
|
};
|
2023-05-11 08:53:19 -07:00
|
|
|
u32 tx_flags:12;
|
|
|
|
u32 type:4; /* &ice_tx_buf_type */
|
|
|
|
u32 vid:16;
|
2018-03-20 07:58:13 -07:00
|
|
|
DEFINE_DMA_UNMAP_LEN(len);
|
ice: Reorganize tx_buf and ring structs
Use more efficient structure ordering by using the pahole tool
and a lot of code inspection to get hot cache lines to have
packed data (no holes if possible) and adjacent warm data.
ice_ring prior to this change:
/* size: 192, cachelines: 3, members: 23 */
/* sum members: 158, holes: 4, sum holes: 12 */
/* padding: 22 */
ice_ring after this change:
/* size: 192, cachelines: 3, members: 25 */
/* sum members: 162, holes: 1, sum holes: 1 */
/* padding: 29 */
ice_tx_buf prior to this change:
/* size: 48, cachelines: 1, members: 7 */
/* sum members: 38, holes: 2, sum holes: 6 */
/* padding: 4 */
/* last cacheline: 48 bytes */
ice_tx_buf after this change:
/* size: 40, cachelines: 1, members: 7 */
/* sum members: 38, holes: 1, sum holes: 2 */
/* last cacheline: 40 bytes */
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-04-16 10:24:34 -07:00
|
|
|
DEFINE_DMA_UNMAP_ADDR(dma);
|
2018-03-20 07:58:13 -07:00
|
|
|
};
|
|
|
|
|
2018-03-20 07:58:15 -07:00
|
|
|
struct ice_tx_offload_params {
|
ice: Reorganize tx_buf and ring structs
Use more efficient structure ordering by using the pahole tool
and a lot of code inspection to get hot cache lines to have
packed data (no holes if possible) and adjacent warm data.
ice_ring prior to this change:
/* size: 192, cachelines: 3, members: 23 */
/* sum members: 158, holes: 4, sum holes: 12 */
/* padding: 22 */
ice_ring after this change:
/* size: 192, cachelines: 3, members: 25 */
/* sum members: 162, holes: 1, sum holes: 1 */
/* padding: 29 */
ice_tx_buf prior to this change:
/* size: 48, cachelines: 1, members: 7 */
/* sum members: 38, holes: 2, sum holes: 6 */
/* padding: 4 */
/* last cacheline: 48 bytes */
ice_tx_buf after this change:
/* size: 40, cachelines: 1, members: 7 */
/* sum members: 38, holes: 1, sum holes: 2 */
/* last cacheline: 40 bytes */
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-04-16 10:24:34 -07:00
|
|
|
u64 cd_qw1;
|
2021-08-19 13:59:58 +02:00
|
|
|
struct ice_tx_ring *tx_ring;
|
2018-03-20 07:58:15 -07:00
|
|
|
u32 td_cmd;
|
|
|
|
u32 td_offset;
|
|
|
|
u32 td_l2tag1;
|
|
|
|
u32 cd_tunnel_params;
|
ice: Reorganize tx_buf and ring structs
Use more efficient structure ordering by using the pahole tool
and a lot of code inspection to get hot cache lines to have
packed data (no holes if possible) and adjacent warm data.
ice_ring prior to this change:
/* size: 192, cachelines: 3, members: 23 */
/* sum members: 158, holes: 4, sum holes: 12 */
/* padding: 22 */
ice_ring after this change:
/* size: 192, cachelines: 3, members: 25 */
/* sum members: 162, holes: 1, sum holes: 1 */
/* padding: 29 */
ice_tx_buf prior to this change:
/* size: 48, cachelines: 1, members: 7 */
/* sum members: 38, holes: 2, sum holes: 6 */
/* padding: 4 */
/* last cacheline: 48 bytes */
ice_tx_buf after this change:
/* size: 40, cachelines: 1, members: 7 */
/* sum members: 38, holes: 1, sum holes: 2 */
/* last cacheline: 40 bytes */
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-04-16 10:24:34 -07:00
|
|
|
u16 cd_l2tag2;
|
|
|
|
u8 header_len;
|
2018-03-20 07:58:15 -07:00
|
|
|
};
|
|
|
|
|
2018-03-20 07:58:13 -07:00
|
|
|
struct ice_rx_buf {
|
2021-09-22 09:56:03 +02:00
|
|
|
dma_addr_t dma;
|
|
|
|
struct page *page;
|
|
|
|
unsigned int page_offset;
|
2023-01-31 21:44:56 +01:00
|
|
|
unsigned int pgcnt;
|
2023-01-31 21:44:59 +01:00
|
|
|
unsigned int act;
|
2023-01-31 21:44:56 +01:00
|
|
|
unsigned int pagecnt_bias;
|
2018-03-20 07:58:13 -07:00
|
|
|
};
|
2018-03-20 07:58:10 -07:00
|
|
|
|
2018-03-20 07:58:14 -07:00
|
|
|
struct ice_q_stats {
|
|
|
|
u64 pkts;
|
|
|
|
u64 bytes;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct ice_txq_stats {
|
|
|
|
u64 restart_q;
|
|
|
|
u64 tx_busy;
|
|
|
|
u64 tx_linearize;
|
2018-08-09 06:29:53 -07:00
|
|
|
int prev_pkt; /* negative if no pending Tx descriptors */
|
2018-03-20 07:58:14 -07:00
|
|
|
};
|
|
|
|
|
|
|
|
struct ice_rxq_stats {
|
|
|
|
u64 non_eop_descs;
|
|
|
|
u64 alloc_page_failed;
|
|
|
|
u64 alloc_buf_failed;
|
|
|
|
};
|
|
|
|
|
ice: Accumulate ring statistics over reset
Resets may occur with or without user interaction. For example, a TX hang
or reconfiguration of parameters will result in a reset. During reset, the
VSI is freed, freeing any statistics structures inside as well. This would
create an issue for the user where a reset happens in the background,
statistics set to zero, and the user checks ring statistics expecting them
to be populated.
To ensure this doesn't happen, accumulate ring statistics over reset.
Define a new ring statistics structure, ice_ring_stats. The new structure
lives in the VSI's parent, preserving ring statistics when VSI is freed.
1. Define a new structure vsi_ring_stats in the PF scope
2. Allocate/free stats only during probe, unload, or change in ring size
3. Replace previous ring statistics functionality with new structure
Signed-off-by: Benjamin Mikailenko <benjamin.mikailenko@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-11-18 16:20:02 -05:00
|
|
|
struct ice_ring_stats {
|
|
|
|
struct rcu_head rcu; /* to avoid race on free */
|
|
|
|
struct ice_q_stats stats;
|
|
|
|
struct u64_stats_sync syncp;
|
|
|
|
union {
|
|
|
|
struct ice_txq_stats tx_stats;
|
|
|
|
struct ice_rxq_stats rx_stats;
|
|
|
|
};
|
|
|
|
};
|
|
|
|
|
2021-03-02 10:12:02 -08:00
|
|
|
enum ice_ring_state_t {
|
|
|
|
ICE_TX_XPS_INIT_DONE,
|
|
|
|
ICE_TX_NBITS,
|
|
|
|
};
|
|
|
|
|
2018-03-20 07:58:10 -07:00
|
|
|
/* this enum matches hardware bits and is meant to be used by DYN_CTLN
|
|
|
|
* registers and QINT registers or more generally anywhere in the manual
|
|
|
|
* mentioning ITR_INDX, ITR_NONE cannot be used as an index 'n' into any
|
|
|
|
* register but instead is a special value meaning "don't update" ITR0/1/2.
|
|
|
|
*/
|
|
|
|
enum ice_dyn_idx_t {
|
|
|
|
ICE_IDX_ITR0 = 0,
|
|
|
|
ICE_IDX_ITR1 = 1,
|
|
|
|
ICE_IDX_ITR2 = 2,
|
|
|
|
ICE_ITR_NONE = 3 /* ITR_NONE must not be used as an index */
|
|
|
|
};
|
|
|
|
|
2018-03-20 07:58:13 -07:00
|
|
|
/* Header split modes defined by DTYPE field of Rx RLAN context */
|
|
|
|
enum ice_rx_dtype {
|
|
|
|
ICE_RX_DTYPE_NO_SPLIT = 0,
|
|
|
|
ICE_RX_DTYPE_HEADER_SPLIT = 1,
|
|
|
|
ICE_RX_DTYPE_SPLIT_ALWAYS = 2,
|
|
|
|
};
|
|
|
|
|
2023-12-05 22:08:34 +01:00
|
|
|
struct ice_pkt_ctx {
|
|
|
|
u64 cached_phctime;
|
2023-12-05 22:08:39 +01:00
|
|
|
__be16 vlan_proto;
|
2023-12-05 22:08:34 +01:00
|
|
|
};
|
|
|
|
|
2023-12-05 22:08:33 +01:00
|
|
|
struct ice_xdp_buff {
|
|
|
|
struct xdp_buff xdp_buff;
|
|
|
|
const union ice_32b_rx_flex_desc *eop_desc;
|
2023-12-05 22:08:34 +01:00
|
|
|
const struct ice_pkt_ctx *pkt_ctx;
|
2023-12-05 22:08:33 +01:00
|
|
|
};
|
|
|
|
|
|
|
|
/* Required for compatibility with xdp_buffs from xsk_pool */
|
|
|
|
static_assert(offsetof(struct ice_xdp_buff, xdp_buff) == 0);
|
|
|
|
|
2018-03-20 07:58:10 -07:00
|
|
|
/* indices into GLINT_ITR registers */
|
|
|
|
#define ICE_RX_ITR ICE_IDX_ITR0
|
2018-03-20 07:58:13 -07:00
|
|
|
#define ICE_TX_ITR ICE_IDX_ITR1
|
2018-12-19 10:03:29 -08:00
|
|
|
#define ICE_ITR_8K 124
|
2018-09-19 17:43:05 -07:00
|
|
|
#define ICE_ITR_20K 50
|
2021-03-31 14:16:59 -07:00
|
|
|
#define ICE_ITR_MAX 8160 /* 0x1FE0 */
|
|
|
|
#define ICE_DFLT_TX_ITR ICE_ITR_20K
|
|
|
|
#define ICE_DFLT_RX_ITR ICE_ITR_20K
|
|
|
|
enum ice_dynamic_itr {
|
|
|
|
ITR_STATIC = 0,
|
|
|
|
ITR_DYNAMIC = 1
|
|
|
|
};
|
|
|
|
|
|
|
|
#define ITR_IS_DYNAMIC(rc) ((rc)->itr_mode == ITR_DYNAMIC)
|
2019-02-19 15:04:10 -08:00
|
|
|
#define ICE_ITR_GRAN_S 1 /* ITR granularity is always 2us */
|
2019-02-08 12:50:55 -08:00
|
|
|
#define ICE_ITR_GRAN_US BIT(ICE_ITR_GRAN_S)
|
2018-12-19 10:03:29 -08:00
|
|
|
#define ICE_ITR_MASK 0x1FFE /* ITR register value alignment mask */
|
2020-02-13 13:31:23 -08:00
|
|
|
#define ITR_REG_ALIGN(setting) ((setting) & ICE_ITR_MASK)
|
2018-03-20 07:58:10 -07:00
|
|
|
|
2018-09-19 17:23:19 -07:00
|
|
|
#define ICE_DFLT_INTRL 0
|
2019-02-28 15:25:55 -08:00
|
|
|
#define ICE_MAX_INTRL 236
|
2018-03-20 07:58:10 -07:00
|
|
|
|
2019-07-25 01:55:32 -07:00
|
|
|
#define ICE_IN_WB_ON_ITR_MODE 255
|
|
|
|
/* Sets WB_ON_ITR and assumes INTENA bit is already cleared, which allows
|
|
|
|
* setting the MSK_M bit to tell hardware to ignore the INTENA_M bit. Also,
|
|
|
|
* set the write-back latency to the usecs passed in.
|
|
|
|
*/
|
|
|
|
#define ICE_GLINT_DYN_CTL_WB_ON_ITR(usecs, itr_idx) \
|
|
|
|
((((usecs) << (GLINT_DYN_CTL_INTERVAL_S - ICE_ITR_GRAN_S)) & \
|
|
|
|
GLINT_DYN_CTL_INTERVAL_M) | \
|
|
|
|
(((itr_idx) << GLINT_DYN_CTL_ITR_INDX_S) & \
|
|
|
|
GLINT_DYN_CTL_ITR_INDX_M) | GLINT_DYN_CTL_INTENA_MSK_M | \
|
|
|
|
GLINT_DYN_CTL_WB_ON_ITR_M)
|
|
|
|
|
2018-03-20 07:58:13 -07:00
|
|
|
/* Legacy or Advanced Mode Queue */
|
|
|
|
#define ICE_TX_ADVANCED 0
|
|
|
|
#define ICE_TX_LEGACY 1
|
|
|
|
|
2018-03-20 07:58:11 -07:00
|
|
|
/* descriptor ring, associated with a VSI */
|
2021-08-19 13:59:58 +02:00
|
|
|
struct ice_rx_ring {
|
ice: Reorganize tx_buf and ring structs
Use more efficient structure ordering by using the pahole tool
and a lot of code inspection to get hot cache lines to have
packed data (no holes if possible) and adjacent warm data.
ice_ring prior to this change:
/* size: 192, cachelines: 3, members: 23 */
/* sum members: 158, holes: 4, sum holes: 12 */
/* padding: 22 */
ice_ring after this change:
/* size: 192, cachelines: 3, members: 25 */
/* sum members: 162, holes: 1, sum holes: 1 */
/* padding: 29 */
ice_tx_buf prior to this change:
/* size: 48, cachelines: 1, members: 7 */
/* sum members: 38, holes: 2, sum holes: 6 */
/* padding: 4 */
/* last cacheline: 48 bytes */
ice_tx_buf after this change:
/* size: 40, cachelines: 1, members: 7 */
/* sum members: 38, holes: 1, sum holes: 2 */
/* last cacheline: 40 bytes */
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-04-16 10:24:34 -07:00
|
|
|
/* CL1 - 1st cacheline starts here */
|
2018-03-20 07:58:13 -07:00
|
|
|
void *desc; /* Descriptor ring memory */
|
2018-03-20 07:58:11 -07:00
|
|
|
struct device *dev; /* Used for DMA mapping */
|
|
|
|
struct net_device *netdev; /* netdev ring maps to */
|
|
|
|
struct ice_vsi *vsi; /* Backreference to associated VSI */
|
|
|
|
struct ice_q_vector *q_vector; /* Backreference to associated vector */
|
2018-03-20 07:58:13 -07:00
|
|
|
u8 __iomem *tail;
|
ice: Add support for XDP multi-buffer on Rx side
Ice driver needs to be a bit reworked on Rx data path in order to
support multi-buffer XDP. For skb path, it currently works in a way that
Rx ring carries pointer to skb so if driver didn't manage to combine
fragmented frame at current NAPI instance, it can restore the state on
next instance and keep looking for last fragment (so descriptor with EOP
bit set). What needs to be achieved is that xdp_buff needs to be
combined in such way (linear + frags part) in the first place. Then skb
will be ready to go in case of XDP_PASS or BPF program being not present
on interface. If BPF program is there, it would work on multi-buffer
XDP. At this point xdp_buff resides directly on Rx ring, so given the
fact that skb will be built straight from xdp_buff, there will be no
further need to carry skb on Rx ring.
Besides removing skb pointer from Rx ring, lots of members have been
moved around within ice_rx_ring. First and foremost reason was to place
rx_buf with xdp_buff on the same cacheline. This means that once we
touch rx_buf (which is a preceding step before touching xdp_buff),
xdp_buff will already be hot in cache. Second thing was that xdp_rxq is
used rather rarely and it occupies a separate cacheline, so maybe it is
better to have it at the end of ice_rx_ring.
Other change that affects ice_rx_ring is the introduction of
ice_rx_ring::first_desc. Its purpose is twofold - first is to propagate
rx_buf->act to all the parts of current xdp_buff after running XDP
program, so that ice_put_rx_buf() that got moved out of the main Rx
processing loop will be able to tak an appriopriate action on each
buffer. Second is for ice_construct_skb().
ice_construct_skb() has a copybreak mechanism which had an explicit
impact on xdp_buff->skb conversion in the new approach when legacy Rx
flag is toggled. It works in a way that linear part is 256 bytes long,
if frame is bigger than that, remaining bytes are going as a frag to
skb_shared_info.
This means while memcpying frags from xdp_buff to newly allocated skb,
care needs to be taken when picking the destination frag array entry.
Upon the time ice_construct_skb() is called, when dealing with
fragmented frame, current rx_buf points to the *last* fragment, but
copybreak needs to be done against the first one. That's where
ice_rx_ring::first_desc helps.
When frame building spans across NAPI polls (DD bit is not set on
current descriptor and xdp->data is not NULL) with current Rx buffer
handling state there might be some problems.
Since calls to ice_put_rx_buf() were pulled out of the main Rx
processing loop and were scoped from cached_ntc to current ntc, remember
that now mentioned function relies on rx_buf->act, which is set within
ice_run_xdp(). ice_run_xdp() is called when EOP bit was found, so
currently we could put Rx buffer with rx_buf->act being *uninitialized*.
To address this, change scoping to rely on first_desc on both boundaries
instead.
This also implies that cleaned_count which is used as an input to
ice_alloc_rx_buffers() and tells how many new buffers should be refilled
has to be adjusted. If it stayed as is, what could happen is a case
where ntc would go over ntu.
Therefore, remove cleaned_count altogether and use against allocing
routine newly introduced ICE_RX_DESC_UNUSED() macro which is an
equivalent of ICE_DESC_UNUSED() dedicated for Rx side and based on
struct ice_rx_ring::first_desc instead of next_to_clean.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Link: https://lore.kernel.org/bpf/20230131204506.219292-11-maciej.fijalkowski@intel.com
2023-01-31 21:45:03 +01:00
|
|
|
u16 q_index; /* Queue number of ring */
|
|
|
|
|
|
|
|
u16 count; /* Number of descriptors */
|
|
|
|
u16 reg_idx; /* HW register index of the ring */
|
|
|
|
u16 next_to_alloc;
|
2023-12-05 22:08:33 +01:00
|
|
|
|
2018-03-20 07:58:13 -07:00
|
|
|
union {
|
|
|
|
struct ice_rx_buf *rx_buf;
|
2021-09-22 09:56:03 +02:00
|
|
|
struct xdp_buff **xdp_buf;
|
2018-03-20 07:58:13 -07:00
|
|
|
};
|
2023-12-05 22:08:33 +01:00
|
|
|
/* CL2 - 2nd cacheline starts here */
|
|
|
|
union {
|
|
|
|
struct ice_xdp_buff xdp_ext;
|
|
|
|
struct xdp_buff xdp;
|
|
|
|
};
|
2021-08-19 13:59:58 +02:00
|
|
|
/* CL3 - 3rd cacheline starts here */
|
2023-12-05 22:08:34 +01:00
|
|
|
union {
|
|
|
|
struct ice_pkt_ctx pkt_ctx;
|
2023-12-05 22:08:39 +01:00
|
|
|
struct {
|
|
|
|
u64 cached_phctime;
|
|
|
|
__be16 vlan_proto;
|
|
|
|
};
|
2023-12-05 22:08:34 +01:00
|
|
|
};
|
ice: Add support for XDP multi-buffer on Rx side
Ice driver needs to be a bit reworked on Rx data path in order to
support multi-buffer XDP. For skb path, it currently works in a way that
Rx ring carries pointer to skb so if driver didn't manage to combine
fragmented frame at current NAPI instance, it can restore the state on
next instance and keep looking for last fragment (so descriptor with EOP
bit set). What needs to be achieved is that xdp_buff needs to be
combined in such way (linear + frags part) in the first place. Then skb
will be ready to go in case of XDP_PASS or BPF program being not present
on interface. If BPF program is there, it would work on multi-buffer
XDP. At this point xdp_buff resides directly on Rx ring, so given the
fact that skb will be built straight from xdp_buff, there will be no
further need to carry skb on Rx ring.
Besides removing skb pointer from Rx ring, lots of members have been
moved around within ice_rx_ring. First and foremost reason was to place
rx_buf with xdp_buff on the same cacheline. This means that once we
touch rx_buf (which is a preceding step before touching xdp_buff),
xdp_buff will already be hot in cache. Second thing was that xdp_rxq is
used rather rarely and it occupies a separate cacheline, so maybe it is
better to have it at the end of ice_rx_ring.
Other change that affects ice_rx_ring is the introduction of
ice_rx_ring::first_desc. Its purpose is twofold - first is to propagate
rx_buf->act to all the parts of current xdp_buff after running XDP
program, so that ice_put_rx_buf() that got moved out of the main Rx
processing loop will be able to tak an appriopriate action on each
buffer. Second is for ice_construct_skb().
ice_construct_skb() has a copybreak mechanism which had an explicit
impact on xdp_buff->skb conversion in the new approach when legacy Rx
flag is toggled. It works in a way that linear part is 256 bytes long,
if frame is bigger than that, remaining bytes are going as a frag to
skb_shared_info.
This means while memcpying frags from xdp_buff to newly allocated skb,
care needs to be taken when picking the destination frag array entry.
Upon the time ice_construct_skb() is called, when dealing with
fragmented frame, current rx_buf points to the *last* fragment, but
copybreak needs to be done against the first one. That's where
ice_rx_ring::first_desc helps.
When frame building spans across NAPI polls (DD bit is not set on
current descriptor and xdp->data is not NULL) with current Rx buffer
handling state there might be some problems.
Since calls to ice_put_rx_buf() were pulled out of the main Rx
processing loop and were scoped from cached_ntc to current ntc, remember
that now mentioned function relies on rx_buf->act, which is set within
ice_run_xdp(). ice_run_xdp() is called when EOP bit was found, so
currently we could put Rx buffer with rx_buf->act being *uninitialized*.
To address this, change scoping to rely on first_desc on both boundaries
instead.
This also implies that cleaned_count which is used as an input to
ice_alloc_rx_buffers() and tells how many new buffers should be refilled
has to be adjusted. If it stayed as is, what could happen is a case
where ntc would go over ntu.
Therefore, remove cleaned_count altogether and use against allocing
routine newly introduced ICE_RX_DESC_UNUSED() macro which is an
equivalent of ICE_DESC_UNUSED() dedicated for Rx side and based on
struct ice_rx_ring::first_desc instead of next_to_clean.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Link: https://lore.kernel.org/bpf/20230131204506.219292-11-maciej.fijalkowski@intel.com
2023-01-31 21:45:03 +01:00
|
|
|
struct bpf_prog *xdp_prog;
|
|
|
|
u16 rx_offset;
|
2018-03-20 07:58:13 -07:00
|
|
|
|
|
|
|
/* used in interrupt processing */
|
|
|
|
u16 next_to_use;
|
|
|
|
u16 next_to_clean;
|
ice: Add support for XDP multi-buffer on Rx side
Ice driver needs to be a bit reworked on Rx data path in order to
support multi-buffer XDP. For skb path, it currently works in a way that
Rx ring carries pointer to skb so if driver didn't manage to combine
fragmented frame at current NAPI instance, it can restore the state on
next instance and keep looking for last fragment (so descriptor with EOP
bit set). What needs to be achieved is that xdp_buff needs to be
combined in such way (linear + frags part) in the first place. Then skb
will be ready to go in case of XDP_PASS or BPF program being not present
on interface. If BPF program is there, it would work on multi-buffer
XDP. At this point xdp_buff resides directly on Rx ring, so given the
fact that skb will be built straight from xdp_buff, there will be no
further need to carry skb on Rx ring.
Besides removing skb pointer from Rx ring, lots of members have been
moved around within ice_rx_ring. First and foremost reason was to place
rx_buf with xdp_buff on the same cacheline. This means that once we
touch rx_buf (which is a preceding step before touching xdp_buff),
xdp_buff will already be hot in cache. Second thing was that xdp_rxq is
used rather rarely and it occupies a separate cacheline, so maybe it is
better to have it at the end of ice_rx_ring.
Other change that affects ice_rx_ring is the introduction of
ice_rx_ring::first_desc. Its purpose is twofold - first is to propagate
rx_buf->act to all the parts of current xdp_buff after running XDP
program, so that ice_put_rx_buf() that got moved out of the main Rx
processing loop will be able to tak an appriopriate action on each
buffer. Second is for ice_construct_skb().
ice_construct_skb() has a copybreak mechanism which had an explicit
impact on xdp_buff->skb conversion in the new approach when legacy Rx
flag is toggled. It works in a way that linear part is 256 bytes long,
if frame is bigger than that, remaining bytes are going as a frag to
skb_shared_info.
This means while memcpying frags from xdp_buff to newly allocated skb,
care needs to be taken when picking the destination frag array entry.
Upon the time ice_construct_skb() is called, when dealing with
fragmented frame, current rx_buf points to the *last* fragment, but
copybreak needs to be done against the first one. That's where
ice_rx_ring::first_desc helps.
When frame building spans across NAPI polls (DD bit is not set on
current descriptor and xdp->data is not NULL) with current Rx buffer
handling state there might be some problems.
Since calls to ice_put_rx_buf() were pulled out of the main Rx
processing loop and were scoped from cached_ntc to current ntc, remember
that now mentioned function relies on rx_buf->act, which is set within
ice_run_xdp(). ice_run_xdp() is called when EOP bit was found, so
currently we could put Rx buffer with rx_buf->act being *uninitialized*.
To address this, change scoping to rely on first_desc on both boundaries
instead.
This also implies that cleaned_count which is used as an input to
ice_alloc_rx_buffers() and tells how many new buffers should be refilled
has to be adjusted. If it stayed as is, what could happen is a case
where ntc would go over ntu.
Therefore, remove cleaned_count altogether and use against allocing
routine newly introduced ICE_RX_DESC_UNUSED() macro which is an
equivalent of ICE_DESC_UNUSED() dedicated for Rx side and based on
struct ice_rx_ring::first_desc instead of next_to_clean.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Link: https://lore.kernel.org/bpf/20230131204506.219292-11-maciej.fijalkowski@intel.com
2023-01-31 21:45:03 +01:00
|
|
|
u16 first_desc;
|
2018-03-20 07:58:14 -07:00
|
|
|
|
|
|
|
/* stats structs */
|
ice: Accumulate ring statistics over reset
Resets may occur with or without user interaction. For example, a TX hang
or reconfiguration of parameters will result in a reset. During reset, the
VSI is freed, freeing any statistics structures inside as well. This would
create an issue for the user where a reset happens in the background,
statistics set to zero, and the user checks ring statistics expecting them
to be populated.
To ensure this doesn't happen, accumulate ring statistics over reset.
Define a new ring statistics structure, ice_ring_stats. The new structure
lives in the VSI's parent, preserving ring statistics when VSI is freed.
1. Define a new structure vsi_ring_stats in the PF scope
2. Allocate/free stats only during probe, unload, or change in ring size
3. Replace previous ring statistics functionality with new structure
Signed-off-by: Benjamin Mikailenko <benjamin.mikailenko@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-11-18 16:20:02 -05:00
|
|
|
struct ice_ring_stats *ring_stats;
|
2018-03-20 07:58:14 -07:00
|
|
|
|
2018-03-20 07:58:11 -07:00
|
|
|
struct rcu_head rcu; /* to avoid race on free */
|
ice: Add support for XDP multi-buffer on Rx side
Ice driver needs to be a bit reworked on Rx data path in order to
support multi-buffer XDP. For skb path, it currently works in a way that
Rx ring carries pointer to skb so if driver didn't manage to combine
fragmented frame at current NAPI instance, it can restore the state on
next instance and keep looking for last fragment (so descriptor with EOP
bit set). What needs to be achieved is that xdp_buff needs to be
combined in such way (linear + frags part) in the first place. Then skb
will be ready to go in case of XDP_PASS or BPF program being not present
on interface. If BPF program is there, it would work on multi-buffer
XDP. At this point xdp_buff resides directly on Rx ring, so given the
fact that skb will be built straight from xdp_buff, there will be no
further need to carry skb on Rx ring.
Besides removing skb pointer from Rx ring, lots of members have been
moved around within ice_rx_ring. First and foremost reason was to place
rx_buf with xdp_buff on the same cacheline. This means that once we
touch rx_buf (which is a preceding step before touching xdp_buff),
xdp_buff will already be hot in cache. Second thing was that xdp_rxq is
used rather rarely and it occupies a separate cacheline, so maybe it is
better to have it at the end of ice_rx_ring.
Other change that affects ice_rx_ring is the introduction of
ice_rx_ring::first_desc. Its purpose is twofold - first is to propagate
rx_buf->act to all the parts of current xdp_buff after running XDP
program, so that ice_put_rx_buf() that got moved out of the main Rx
processing loop will be able to tak an appriopriate action on each
buffer. Second is for ice_construct_skb().
ice_construct_skb() has a copybreak mechanism which had an explicit
impact on xdp_buff->skb conversion in the new approach when legacy Rx
flag is toggled. It works in a way that linear part is 256 bytes long,
if frame is bigger than that, remaining bytes are going as a frag to
skb_shared_info.
This means while memcpying frags from xdp_buff to newly allocated skb,
care needs to be taken when picking the destination frag array entry.
Upon the time ice_construct_skb() is called, when dealing with
fragmented frame, current rx_buf points to the *last* fragment, but
copybreak needs to be done against the first one. That's where
ice_rx_ring::first_desc helps.
When frame building spans across NAPI polls (DD bit is not set on
current descriptor and xdp->data is not NULL) with current Rx buffer
handling state there might be some problems.
Since calls to ice_put_rx_buf() were pulled out of the main Rx
processing loop and were scoped from cached_ntc to current ntc, remember
that now mentioned function relies on rx_buf->act, which is set within
ice_run_xdp(). ice_run_xdp() is called when EOP bit was found, so
currently we could put Rx buffer with rx_buf->act being *uninitialized*.
To address this, change scoping to rely on first_desc on both boundaries
instead.
This also implies that cleaned_count which is used as an input to
ice_alloc_rx_buffers() and tells how many new buffers should be refilled
has to be adjusted. If it stayed as is, what could happen is a case
where ntc would go over ntu.
Therefore, remove cleaned_count altogether and use against allocing
routine newly introduced ICE_RX_DESC_UNUSED() macro which is an
equivalent of ICE_DESC_UNUSED() dedicated for Rx side and based on
struct ice_rx_ring::first_desc instead of next_to_clean.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Link: https://lore.kernel.org/bpf/20230131204506.219292-11-maciej.fijalkowski@intel.com
2023-01-31 21:45:03 +01:00
|
|
|
/* CL4 - 4th cacheline starts here */
|
2021-10-15 16:35:15 -07:00
|
|
|
struct ice_channel *ch;
|
2021-08-19 14:00:01 +02:00
|
|
|
struct ice_tx_ring *xdp_ring;
|
2023-12-05 22:08:33 +01:00
|
|
|
struct ice_rx_ring *next; /* pointer to next ring in q_vector */
|
2020-08-28 10:26:15 +02:00
|
|
|
struct xsk_buff_pool *xsk_pool;
|
2024-01-24 20:15:55 +01:00
|
|
|
u32 nr_frags;
|
2021-08-19 13:59:58 +02:00
|
|
|
dma_addr_t dma; /* physical address of ring */
|
ice: Add support for XDP multi-buffer on Rx side
Ice driver needs to be a bit reworked on Rx data path in order to
support multi-buffer XDP. For skb path, it currently works in a way that
Rx ring carries pointer to skb so if driver didn't manage to combine
fragmented frame at current NAPI instance, it can restore the state on
next instance and keep looking for last fragment (so descriptor with EOP
bit set). What needs to be achieved is that xdp_buff needs to be
combined in such way (linear + frags part) in the first place. Then skb
will be ready to go in case of XDP_PASS or BPF program being not present
on interface. If BPF program is there, it would work on multi-buffer
XDP. At this point xdp_buff resides directly on Rx ring, so given the
fact that skb will be built straight from xdp_buff, there will be no
further need to carry skb on Rx ring.
Besides removing skb pointer from Rx ring, lots of members have been
moved around within ice_rx_ring. First and foremost reason was to place
rx_buf with xdp_buff on the same cacheline. This means that once we
touch rx_buf (which is a preceding step before touching xdp_buff),
xdp_buff will already be hot in cache. Second thing was that xdp_rxq is
used rather rarely and it occupies a separate cacheline, so maybe it is
better to have it at the end of ice_rx_ring.
Other change that affects ice_rx_ring is the introduction of
ice_rx_ring::first_desc. Its purpose is twofold - first is to propagate
rx_buf->act to all the parts of current xdp_buff after running XDP
program, so that ice_put_rx_buf() that got moved out of the main Rx
processing loop will be able to tak an appriopriate action on each
buffer. Second is for ice_construct_skb().
ice_construct_skb() has a copybreak mechanism which had an explicit
impact on xdp_buff->skb conversion in the new approach when legacy Rx
flag is toggled. It works in a way that linear part is 256 bytes long,
if frame is bigger than that, remaining bytes are going as a frag to
skb_shared_info.
This means while memcpying frags from xdp_buff to newly allocated skb,
care needs to be taken when picking the destination frag array entry.
Upon the time ice_construct_skb() is called, when dealing with
fragmented frame, current rx_buf points to the *last* fragment, but
copybreak needs to be done against the first one. That's where
ice_rx_ring::first_desc helps.
When frame building spans across NAPI polls (DD bit is not set on
current descriptor and xdp->data is not NULL) with current Rx buffer
handling state there might be some problems.
Since calls to ice_put_rx_buf() were pulled out of the main Rx
processing loop and were scoped from cached_ntc to current ntc, remember
that now mentioned function relies on rx_buf->act, which is set within
ice_run_xdp(). ice_run_xdp() is called when EOP bit was found, so
currently we could put Rx buffer with rx_buf->act being *uninitialized*.
To address this, change scoping to rely on first_desc on both boundaries
instead.
This also implies that cleaned_count which is used as an input to
ice_alloc_rx_buffers() and tells how many new buffers should be refilled
has to be adjusted. If it stayed as is, what could happen is a case
where ntc would go over ntu.
Therefore, remove cleaned_count altogether and use against allocing
routine newly introduced ICE_RX_DESC_UNUSED() macro which is an
equivalent of ICE_DESC_UNUSED() dedicated for Rx side and based on
struct ice_rx_ring::first_desc instead of next_to_clean.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Link: https://lore.kernel.org/bpf/20230131204506.219292-11-maciej.fijalkowski@intel.com
2023-01-31 21:45:03 +01:00
|
|
|
u16 rx_buf_len;
|
2021-08-19 13:59:58 +02:00
|
|
|
u8 dcb_tc; /* Traffic class of ring */
|
|
|
|
u8 ptp_rx;
|
2022-07-27 09:24:05 +02:00
|
|
|
#define ICE_RX_FLAGS_RING_BUILD_SKB BIT(1)
|
|
|
|
#define ICE_RX_FLAGS_CRC_STRIP_DIS BIT(2)
|
2024-03-01 12:54:13 +01:00
|
|
|
#define ICE_RX_FLAGS_MULTIDEV BIT(3)
|
2019-11-04 09:38:56 -08:00
|
|
|
u8 flags;
|
ice: Add support for XDP multi-buffer on Rx side
Ice driver needs to be a bit reworked on Rx data path in order to
support multi-buffer XDP. For skb path, it currently works in a way that
Rx ring carries pointer to skb so if driver didn't manage to combine
fragmented frame at current NAPI instance, it can restore the state on
next instance and keep looking for last fragment (so descriptor with EOP
bit set). What needs to be achieved is that xdp_buff needs to be
combined in such way (linear + frags part) in the first place. Then skb
will be ready to go in case of XDP_PASS or BPF program being not present
on interface. If BPF program is there, it would work on multi-buffer
XDP. At this point xdp_buff resides directly on Rx ring, so given the
fact that skb will be built straight from xdp_buff, there will be no
further need to carry skb on Rx ring.
Besides removing skb pointer from Rx ring, lots of members have been
moved around within ice_rx_ring. First and foremost reason was to place
rx_buf with xdp_buff on the same cacheline. This means that once we
touch rx_buf (which is a preceding step before touching xdp_buff),
xdp_buff will already be hot in cache. Second thing was that xdp_rxq is
used rather rarely and it occupies a separate cacheline, so maybe it is
better to have it at the end of ice_rx_ring.
Other change that affects ice_rx_ring is the introduction of
ice_rx_ring::first_desc. Its purpose is twofold - first is to propagate
rx_buf->act to all the parts of current xdp_buff after running XDP
program, so that ice_put_rx_buf() that got moved out of the main Rx
processing loop will be able to tak an appriopriate action on each
buffer. Second is for ice_construct_skb().
ice_construct_skb() has a copybreak mechanism which had an explicit
impact on xdp_buff->skb conversion in the new approach when legacy Rx
flag is toggled. It works in a way that linear part is 256 bytes long,
if frame is bigger than that, remaining bytes are going as a frag to
skb_shared_info.
This means while memcpying frags from xdp_buff to newly allocated skb,
care needs to be taken when picking the destination frag array entry.
Upon the time ice_construct_skb() is called, when dealing with
fragmented frame, current rx_buf points to the *last* fragment, but
copybreak needs to be done against the first one. That's where
ice_rx_ring::first_desc helps.
When frame building spans across NAPI polls (DD bit is not set on
current descriptor and xdp->data is not NULL) with current Rx buffer
handling state there might be some problems.
Since calls to ice_put_rx_buf() were pulled out of the main Rx
processing loop and were scoped from cached_ntc to current ntc, remember
that now mentioned function relies on rx_buf->act, which is set within
ice_run_xdp(). ice_run_xdp() is called when EOP bit was found, so
currently we could put Rx buffer with rx_buf->act being *uninitialized*.
To address this, change scoping to rely on first_desc on both boundaries
instead.
This also implies that cleaned_count which is used as an input to
ice_alloc_rx_buffers() and tells how many new buffers should be refilled
has to be adjusted. If it stayed as is, what could happen is a case
where ntc would go over ntu.
Therefore, remove cleaned_count altogether and use against allocing
routine newly introduced ICE_RX_DESC_UNUSED() macro which is an
equivalent of ICE_DESC_UNUSED() dedicated for Rx side and based on
struct ice_rx_ring::first_desc instead of next_to_clean.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Link: https://lore.kernel.org/bpf/20230131204506.219292-11-maciej.fijalkowski@intel.com
2023-01-31 21:45:03 +01:00
|
|
|
/* CL5 - 5th cacheline starts here */
|
|
|
|
struct xdp_rxq_info xdp_rxq;
|
2021-08-19 13:59:58 +02:00
|
|
|
} ____cacheline_internodealigned_in_smp;
|
|
|
|
|
|
|
|
struct ice_tx_ring {
|
|
|
|
/* CL1 - 1st cacheline starts here */
|
|
|
|
struct ice_tx_ring *next; /* pointer to next ring in q_vector */
|
|
|
|
void *desc; /* Descriptor ring memory */
|
|
|
|
struct device *dev; /* Used for DMA mapping */
|
|
|
|
u8 __iomem *tail;
|
|
|
|
struct ice_tx_buf *tx_buf;
|
|
|
|
struct ice_q_vector *q_vector; /* Backreference to associated vector */
|
|
|
|
struct net_device *netdev; /* netdev ring maps to */
|
|
|
|
struct ice_vsi *vsi; /* Backreference to associated VSI */
|
|
|
|
/* CL2 - 2nd cacheline starts here */
|
ice: Reorganize tx_buf and ring structs
Use more efficient structure ordering by using the pahole tool
and a lot of code inspection to get hot cache lines to have
packed data (no holes if possible) and adjacent warm data.
ice_ring prior to this change:
/* size: 192, cachelines: 3, members: 23 */
/* sum members: 158, holes: 4, sum holes: 12 */
/* padding: 22 */
ice_ring after this change:
/* size: 192, cachelines: 3, members: 25 */
/* sum members: 162, holes: 1, sum holes: 1 */
/* padding: 29 */
ice_tx_buf prior to this change:
/* size: 48, cachelines: 1, members: 7 */
/* sum members: 38, holes: 2, sum holes: 6 */
/* padding: 4 */
/* last cacheline: 48 bytes */
ice_tx_buf after this change:
/* size: 40, cachelines: 1, members: 7 */
/* sum members: 38, holes: 1, sum holes: 2 */
/* last cacheline: 40 bytes */
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-04-16 10:24:34 -07:00
|
|
|
dma_addr_t dma; /* physical address of ring */
|
ice: optimize XDP_TX workloads
Optimize Tx descriptor cleaning for XDP. Current approach doesn't
really scale and chokes when multiple flows are handled.
Introduce two ring fields, @next_dd and @next_rs that will keep track of
descriptor that should be looked at when the need for cleaning arise and
the descriptor that should have the RS bit set, respectively.
Note that at this point the threshold is a constant (32), but it is
something that we could make configurable.
First thing is to get away from setting RS bit on each descriptor. Let's
do this only once NTU is higher than the currently @next_rs value. In
such case, grab the tx_desc[next_rs], set the RS bit in descriptor and
advance the @next_rs by a 32.
Second thing is to clean the Tx ring only when there are less than 32
free entries. For that case, look up the tx_desc[next_dd] for a DD bit.
This bit is written back by HW to let the driver know that xmit was
successful. It will happen only for those descriptors that had RS bit
set. Clean only 32 descriptors and advance the DD bit.
Actual cleaning routine is moved from ice_napi_poll() down to the
ice_xmit_xdp_ring(). It is safe to do so as XDP ring will not get any
SKBs in there that would rely on interrupts for the cleaning. Nice side
effect is that for rare case of Tx fallback path (that next patch is
going to introduce) we don't have to trigger the SW irq to clean the
ring.
With those two concepts, ring is kept at being almost full, but it is
guaranteed that driver will be able to produce Tx descriptors.
This approach seems to work out well even though the Tx descriptors are
produced in one-by-one manner. Test was conducted with the ice HW
bombarded with packets from HW generator, configured to generate 30
flows.
Xdp2 sample yields the following results:
<snip>
proto 17: 79973066 pkt/s
proto 17: 80018911 pkt/s
proto 17: 80004654 pkt/s
proto 17: 79992395 pkt/s
proto 17: 79975162 pkt/s
proto 17: 79955054 pkt/s
proto 17: 79869168 pkt/s
proto 17: 79823947 pkt/s
proto 17: 79636971 pkt/s
</snip>
As that sample reports the Rx'ed frames, let's look at sar output.
It says that what we Rx'ed we do actually Tx, no noticeable drops.
Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
Average: ens4f1 79842324.00 79842310.40 4678261.17 4678260.38 0.00 0.00 0.00 38.32
with tx_busy staying calm.
When compared to a state before:
Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
Average: ens4f1 90919711.60 42233822.60 5327326.85 2474638.04 0.00 0.00 0.00 43.64
it can be observed that the amount of txpck/s is almost doubled, meaning
that the performance is improved by around 90%. All of this due to the
drops in the driver, previously the tx_busy stat was bumped at a 7mpps
rate.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-08-19 14:00:02 +02:00
|
|
|
struct xsk_buff_pool *xsk_pool;
|
2021-08-19 13:59:58 +02:00
|
|
|
u16 next_to_use;
|
|
|
|
u16 next_to_clean;
|
ice: optimize XDP_TX workloads
Optimize Tx descriptor cleaning for XDP. Current approach doesn't
really scale and chokes when multiple flows are handled.
Introduce two ring fields, @next_dd and @next_rs that will keep track of
descriptor that should be looked at when the need for cleaning arise and
the descriptor that should have the RS bit set, respectively.
Note that at this point the threshold is a constant (32), but it is
something that we could make configurable.
First thing is to get away from setting RS bit on each descriptor. Let's
do this only once NTU is higher than the currently @next_rs value. In
such case, grab the tx_desc[next_rs], set the RS bit in descriptor and
advance the @next_rs by a 32.
Second thing is to clean the Tx ring only when there are less than 32
free entries. For that case, look up the tx_desc[next_dd] for a DD bit.
This bit is written back by HW to let the driver know that xmit was
successful. It will happen only for those descriptors that had RS bit
set. Clean only 32 descriptors and advance the DD bit.
Actual cleaning routine is moved from ice_napi_poll() down to the
ice_xmit_xdp_ring(). It is safe to do so as XDP ring will not get any
SKBs in there that would rely on interrupts for the cleaning. Nice side
effect is that for rare case of Tx fallback path (that next patch is
going to introduce) we don't have to trigger the SW irq to clean the
ring.
With those two concepts, ring is kept at being almost full, but it is
guaranteed that driver will be able to produce Tx descriptors.
This approach seems to work out well even though the Tx descriptors are
produced in one-by-one manner. Test was conducted with the ice HW
bombarded with packets from HW generator, configured to generate 30
flows.
Xdp2 sample yields the following results:
<snip>
proto 17: 79973066 pkt/s
proto 17: 80018911 pkt/s
proto 17: 80004654 pkt/s
proto 17: 79992395 pkt/s
proto 17: 79975162 pkt/s
proto 17: 79955054 pkt/s
proto 17: 79869168 pkt/s
proto 17: 79823947 pkt/s
proto 17: 79636971 pkt/s
</snip>
As that sample reports the Rx'ed frames, let's look at sar output.
It says that what we Rx'ed we do actually Tx, no noticeable drops.
Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
Average: ens4f1 79842324.00 79842310.40 4678261.17 4678260.38 0.00 0.00 0.00 38.32
with tx_busy staying calm.
When compared to a state before:
Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
Average: ens4f1 90919711.60 42233822.60 5327326.85 2474638.04 0.00 0.00 0.00 43.64
it can be observed that the amount of txpck/s is almost doubled, meaning
that the performance is improved by around 90%. All of this due to the
drops in the driver, previously the tx_busy stat was bumped at a 7mpps
rate.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-08-19 14:00:02 +02:00
|
|
|
u16 q_handle; /* Queue handle per TC */
|
|
|
|
u16 reg_idx; /* HW register index of the ring */
|
2021-08-19 13:59:58 +02:00
|
|
|
u16 count; /* Number of descriptors */
|
|
|
|
u16 q_index; /* Queue number of ring */
|
2023-01-31 21:45:04 +01:00
|
|
|
u16 xdp_tx_active;
|
2021-08-19 13:59:58 +02:00
|
|
|
/* stats structs */
|
ice: Accumulate ring statistics over reset
Resets may occur with or without user interaction. For example, a TX hang
or reconfiguration of parameters will result in a reset. During reset, the
VSI is freed, freeing any statistics structures inside as well. This would
create an issue for the user where a reset happens in the background,
statistics set to zero, and the user checks ring statistics expecting them
to be populated.
To ensure this doesn't happen, accumulate ring statistics over reset.
Define a new ring statistics structure, ice_ring_stats. The new structure
lives in the VSI's parent, preserving ring statistics when VSI is freed.
1. Define a new structure vsi_ring_stats in the PF scope
2. Allocate/free stats only during probe, unload, or change in ring size
3. Replace previous ring statistics functionality with new structure
Signed-off-by: Benjamin Mikailenko <benjamin.mikailenko@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2022-11-18 16:20:02 -05:00
|
|
|
struct ice_ring_stats *ring_stats;
|
2021-08-19 13:59:58 +02:00
|
|
|
/* CL3 - 3rd cacheline starts here */
|
|
|
|
struct rcu_head rcu; /* to avoid race on free */
|
|
|
|
DECLARE_BITMAP(xps_state, ICE_TX_NBITS); /* XPS Config State */
|
2021-10-15 16:35:15 -07:00
|
|
|
struct ice_channel *ch;
|
2021-08-19 13:59:58 +02:00
|
|
|
struct ice_ptp_tx *tx_tstamps;
|
2021-08-19 14:00:03 +02:00
|
|
|
spinlock_t tx_lock;
|
ice: Reorganize tx_buf and ring structs
Use more efficient structure ordering by using the pahole tool
and a lot of code inspection to get hot cache lines to have
packed data (no holes if possible) and adjacent warm data.
ice_ring prior to this change:
/* size: 192, cachelines: 3, members: 23 */
/* sum members: 158, holes: 4, sum holes: 12 */
/* padding: 22 */
ice_ring after this change:
/* size: 192, cachelines: 3, members: 25 */
/* sum members: 162, holes: 1, sum holes: 1 */
/* padding: 29 */
ice_tx_buf prior to this change:
/* size: 48, cachelines: 1, members: 7 */
/* sum members: 38, holes: 2, sum holes: 6 */
/* padding: 4 */
/* last cacheline: 48 bytes */
ice_tx_buf after this change:
/* size: 40, cachelines: 1, members: 7 */
/* sum members: 38, holes: 1, sum holes: 2 */
/* last cacheline: 40 bytes */
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-04-16 10:24:34 -07:00
|
|
|
u32 txq_teid; /* Added Tx queue TEID */
|
2022-01-25 17:04:45 +01:00
|
|
|
/* CL4 - 4th cacheline starts here */
|
2021-08-19 13:59:58 +02:00
|
|
|
#define ICE_TX_FLAGS_RING_XDP BIT(0)
|
ice: Add hot path support for 802.1Q and 802.1ad VLAN offloads
Currently the driver only supports 802.1Q VLAN insertion and stripping.
However, once Double VLAN Mode (DVM) is fully supported, then both 802.1Q
and 802.1ad VLAN insertion and stripping will be supported. Unfortunately
the VSI context parameters only allow for one VLAN ethertype at a time
for VLAN offloads so only one or the other VLAN ethertype offload can be
supported at once.
To support this, multiple changes are needed.
Rx path changes:
[1] In DVM, the Rx queue context l2tagsel field needs to be cleared so
the outermost tag shows up in the l2tag2_2nd field of the Rx flex
descriptor. In Single VLAN Mode (SVM), the l2tagsel field should remain
1 to support SVM configurations.
[2] Modify the ice_test_staterr() function to take a __le16 instead of
the ice_32b_rx_flex_desc union pointer so this function can be used for
both rx_desc->wb.status_error0 and rx_desc->wb.status_error1.
[3] Add the new inline function ice_get_vlan_tag_from_rx_desc() that
checks if there is a VLAN tag in l2tag1 or l2tag2_2nd.
[4] In ice_receive_skb(), add a check to see if NETIF_F_HW_VLAN_STAG_RX
is enabled in netdev->features. If it is, then this is the VLAN
ethertype that needs to be added to the stripping VLAN tag. Since
ice_fix_features() prevents CTAG_RX and STAG_RX from being enabled
simultaneously, the VLAN ethertype will only ever be 802.1Q or 802.1ad.
Tx path changes:
[1] In DVM, the VLAN tag needs to be placed in the l2tag2 field of the Tx
context descriptor. The new define ICE_TX_FLAGS_HW_OUTER_SINGLE_VLAN was
added to the list of tx_flags to handle this case.
[2] When the stack requests the VLAN tag to be offloaded on Tx, the
driver needs to set either ICE_TX_FLAGS_HW_OUTER_SINGLE_VLAN or
ICE_TX_FLAGS_HW_VLAN, so the tag is inserted in l2tag2 or l2tag1
respectively. To determine which location to use, set a bit in the Tx
ring flags field during ring allocation that can be used to determine
which field to use in the Tx descriptor. In DVM, always use l2tag2,
and in SVM, always use l2tag1.
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-12-02 08:38:47 -08:00
|
|
|
#define ICE_TX_FLAGS_RING_VLAN_L2TAG1 BIT(1)
|
|
|
|
#define ICE_TX_FLAGS_RING_VLAN_L2TAG2 BIT(2)
|
2021-08-19 13:59:58 +02:00
|
|
|
u8 flags;
|
ice: Reorganize tx_buf and ring structs
Use more efficient structure ordering by using the pahole tool
and a lot of code inspection to get hot cache lines to have
packed data (no holes if possible) and adjacent warm data.
ice_ring prior to this change:
/* size: 192, cachelines: 3, members: 23 */
/* sum members: 158, holes: 4, sum holes: 12 */
/* padding: 22 */
ice_ring after this change:
/* size: 192, cachelines: 3, members: 25 */
/* sum members: 162, holes: 1, sum holes: 1 */
/* padding: 29 */
ice_tx_buf prior to this change:
/* size: 48, cachelines: 1, members: 7 */
/* sum members: 38, holes: 2, sum holes: 6 */
/* padding: 4 */
/* last cacheline: 48 bytes */
ice_tx_buf after this change:
/* size: 40, cachelines: 1, members: 7 */
/* sum members: 38, holes: 1, sum holes: 2 */
/* last cacheline: 40 bytes */
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Anirudh Venkataramanan <anirudh.venkataramanan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2019-04-16 10:24:34 -07:00
|
|
|
u8 dcb_tc; /* Traffic class of ring */
|
2018-03-20 07:58:11 -07:00
|
|
|
} ____cacheline_internodealigned_in_smp;
|
|
|
|
|
2021-08-19 13:59:58 +02:00
|
|
|
static inline bool ice_ring_uses_build_skb(struct ice_rx_ring *ring)
|
2019-10-24 01:11:23 -07:00
|
|
|
{
|
|
|
|
return !!(ring->flags & ICE_RX_FLAGS_RING_BUILD_SKB);
|
|
|
|
}
|
|
|
|
|
2021-08-19 13:59:58 +02:00
|
|
|
static inline void ice_set_ring_build_skb_ena(struct ice_rx_ring *ring)
|
2019-10-24 01:11:23 -07:00
|
|
|
{
|
|
|
|
ring->flags |= ICE_RX_FLAGS_RING_BUILD_SKB;
|
|
|
|
}
|
|
|
|
|
2021-08-19 13:59:58 +02:00
|
|
|
static inline void ice_clear_ring_build_skb_ena(struct ice_rx_ring *ring)
|
2019-10-24 01:11:23 -07:00
|
|
|
{
|
|
|
|
ring->flags &= ~ICE_RX_FLAGS_RING_BUILD_SKB;
|
|
|
|
}
|
|
|
|
|
2021-10-15 16:35:15 -07:00
|
|
|
static inline bool ice_ring_ch_enabled(struct ice_tx_ring *ring)
|
|
|
|
{
|
|
|
|
return !!ring->ch;
|
|
|
|
}
|
|
|
|
|
2021-08-19 13:59:58 +02:00
|
|
|
static inline bool ice_ring_is_xdp(struct ice_tx_ring *ring)
|
2019-11-04 09:38:56 -08:00
|
|
|
{
|
|
|
|
return !!(ring->flags & ICE_TX_FLAGS_RING_XDP);
|
|
|
|
}
|
|
|
|
|
2021-08-19 13:59:57 +02:00
|
|
|
enum ice_container_type {
|
|
|
|
ICE_RX_CONTAINER,
|
|
|
|
ICE_TX_CONTAINER,
|
|
|
|
};
|
|
|
|
|
2018-03-20 07:58:11 -07:00
|
|
|
struct ice_ring_container {
|
2018-12-19 10:03:29 -08:00
|
|
|
/* head of linked-list of rings */
|
2021-08-19 13:59:58 +02:00
|
|
|
union {
|
|
|
|
struct ice_rx_ring *rx_ring;
|
|
|
|
struct ice_tx_ring *tx_ring;
|
|
|
|
};
|
ice: replace custom AIM algorithm with kernel's DIM library
The ice driver has support for adaptive interrupt moderation, an
algorithm for tuning the interrupt rate dynamically. This algorithm
is based on various assumptions about ring size, socket buffer size,
link speed, SKB overhead, ethernet frame overhead and more.
The Linux kernel has support for a dynamic interrupt moderation
algorithm known as "dimlib". Replace the custom driver-specific
implementation of dynamic interrupt moderation with the kernel's
algorithm.
The Intel hardware has a different hardware implementation than the
originators of the dimlib code had to work with, which requires the
driver to use a slightly different set of inputs for the actual
moderation values, while getting all the advice from dimlib of
better/worse, shift left or right.
The change made for this implementation is to use a pair of values
for each of the 5 "slots" that the dimlib moderation expects, and
the driver will program those pairs when dimlib recommends a slot to
use. The currently implementation uses two tables, one for receive
and one for transmit, and the pairs of values in each slot set the
maximum delay of an interrupt and a maximum number of interrupts per
second (both expressed in microseconds).
There are two separate kinds of bugs fixed by using DIMLIB, one is
UDP single stream send was too slow, and the other is that 8K
ping-pong was going to the most aggressive moderation and has much
too high latency.
The overall result of using DIMLIB is that we meet or exceed our
performance expectations set based on the old algorithm.
Co-developed-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Tony Brelinski <tonyx.brelinski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
2021-03-31 14:16:57 -07:00
|
|
|
struct dim dim; /* data for net_dim algorithm */
|
2019-02-19 15:04:05 -08:00
|
|
|
u16 itr_idx; /* index in the interrupt vector */
|
2021-03-31 14:16:59 -07:00
|
|
|
/* this matches the maximum number of ITR bits, but in usec
|
|
|
|
* values, so it is shifted left one bit (bit zero is ignored)
|
2018-12-19 10:03:29 -08:00
|
|
|
*/
|
2022-05-08 19:33:48 -04:00
|
|
|
union {
|
|
|
|
struct {
|
|
|
|
u16 itr_setting:13;
|
|
|
|
u16 itr_reserved:2;
|
|
|
|
u16 itr_mode:1;
|
|
|
|
};
|
|
|
|
u16 itr_settings;
|
|
|
|
};
|
2021-08-19 13:59:57 +02:00
|
|
|
enum ice_container_type type;
|
2018-03-20 07:58:11 -07:00
|
|
|
};
|
|
|
|
|
2019-12-12 03:12:58 -08:00
|
|
|
struct ice_coalesce_stored {
|
|
|
|
u16 itr_tx;
|
|
|
|
u16 itr_rx;
|
|
|
|
u8 intrl;
|
2021-03-02 10:12:05 -08:00
|
|
|
u8 tx_valid;
|
|
|
|
u8 rx_valid;
|
2019-12-12 03:12:58 -08:00
|
|
|
};
|
|
|
|
|
2018-03-20 07:58:11 -07:00
|
|
|
/* iterator for handling rings in ring container */
|
2021-08-19 13:59:58 +02:00
|
|
|
#define ice_for_each_rx_ring(pos, head) \
|
|
|
|
for (pos = (head).rx_ring; pos; pos = pos->next)
|
|
|
|
|
|
|
|
#define ice_for_each_tx_ring(pos, head) \
|
|
|
|
for (pos = (head).tx_ring; pos; pos = pos->next)
|
2018-03-20 07:58:11 -07:00
|
|
|
|
2021-08-19 13:59:58 +02:00
|
|
|
static inline unsigned int ice_rx_pg_order(struct ice_rx_ring *ring)
|
2019-10-24 01:11:22 -07:00
|
|
|
{
|
|
|
|
#if (PAGE_SIZE < 8192)
|
|
|
|
if (ring->rx_buf_len > (PAGE_SIZE / 2))
|
|
|
|
return 1;
|
|
|
|
#endif
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define ice_rx_pg_size(_ring) (PAGE_SIZE << ice_rx_pg_order(_ring))
|
|
|
|
|
2019-11-04 09:38:56 -08:00
|
|
|
union ice_32b_rx_flex_desc;
|
|
|
|
|
ice: Add support for XDP multi-buffer on Rx side
Ice driver needs to be a bit reworked on Rx data path in order to
support multi-buffer XDP. For skb path, it currently works in a way that
Rx ring carries pointer to skb so if driver didn't manage to combine
fragmented frame at current NAPI instance, it can restore the state on
next instance and keep looking for last fragment (so descriptor with EOP
bit set). What needs to be achieved is that xdp_buff needs to be
combined in such way (linear + frags part) in the first place. Then skb
will be ready to go in case of XDP_PASS or BPF program being not present
on interface. If BPF program is there, it would work on multi-buffer
XDP. At this point xdp_buff resides directly on Rx ring, so given the
fact that skb will be built straight from xdp_buff, there will be no
further need to carry skb on Rx ring.
Besides removing skb pointer from Rx ring, lots of members have been
moved around within ice_rx_ring. First and foremost reason was to place
rx_buf with xdp_buff on the same cacheline. This means that once we
touch rx_buf (which is a preceding step before touching xdp_buff),
xdp_buff will already be hot in cache. Second thing was that xdp_rxq is
used rather rarely and it occupies a separate cacheline, so maybe it is
better to have it at the end of ice_rx_ring.
Other change that affects ice_rx_ring is the introduction of
ice_rx_ring::first_desc. Its purpose is twofold - first is to propagate
rx_buf->act to all the parts of current xdp_buff after running XDP
program, so that ice_put_rx_buf() that got moved out of the main Rx
processing loop will be able to tak an appriopriate action on each
buffer. Second is for ice_construct_skb().
ice_construct_skb() has a copybreak mechanism which had an explicit
impact on xdp_buff->skb conversion in the new approach when legacy Rx
flag is toggled. It works in a way that linear part is 256 bytes long,
if frame is bigger than that, remaining bytes are going as a frag to
skb_shared_info.
This means while memcpying frags from xdp_buff to newly allocated skb,
care needs to be taken when picking the destination frag array entry.
Upon the time ice_construct_skb() is called, when dealing with
fragmented frame, current rx_buf points to the *last* fragment, but
copybreak needs to be done against the first one. That's where
ice_rx_ring::first_desc helps.
When frame building spans across NAPI polls (DD bit is not set on
current descriptor and xdp->data is not NULL) with current Rx buffer
handling state there might be some problems.
Since calls to ice_put_rx_buf() were pulled out of the main Rx
processing loop and were scoped from cached_ntc to current ntc, remember
that now mentioned function relies on rx_buf->act, which is set within
ice_run_xdp(). ice_run_xdp() is called when EOP bit was found, so
currently we could put Rx buffer with rx_buf->act being *uninitialized*.
To address this, change scoping to rely on first_desc on both boundaries
instead.
This also implies that cleaned_count which is used as an input to
ice_alloc_rx_buffers() and tells how many new buffers should be refilled
has to be adjusted. If it stayed as is, what could happen is a case
where ntc would go over ntu.
Therefore, remove cleaned_count altogether and use against allocing
routine newly introduced ICE_RX_DESC_UNUSED() macro which is an
equivalent of ICE_DESC_UNUSED() dedicated for Rx side and based on
struct ice_rx_ring::first_desc instead of next_to_clean.
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Alexander Lobakin <alexandr.lobakin@intel.com>
Link: https://lore.kernel.org/bpf/20230131204506.219292-11-maciej.fijalkowski@intel.com
2023-01-31 21:45:03 +01:00
|
|
|
bool ice_alloc_rx_bufs(struct ice_rx_ring *rxr, unsigned int cleaned_count);
|
2018-03-20 07:58:14 -07:00
|
|
|
netdev_tx_t ice_start_xmit(struct sk_buff *skb, struct net_device *netdev);
|
2021-08-06 13:53:56 -07:00
|
|
|
u16
|
|
|
|
ice_select_queue(struct net_device *dev, struct sk_buff *skb,
|
|
|
|
struct net_device *sb_dev);
|
2021-08-19 13:59:58 +02:00
|
|
|
void ice_clean_tx_ring(struct ice_tx_ring *tx_ring);
|
|
|
|
void ice_clean_rx_ring(struct ice_rx_ring *rx_ring);
|
|
|
|
int ice_setup_tx_ring(struct ice_tx_ring *tx_ring);
|
|
|
|
int ice_setup_rx_ring(struct ice_rx_ring *rx_ring);
|
|
|
|
void ice_free_tx_ring(struct ice_tx_ring *tx_ring);
|
|
|
|
void ice_free_rx_ring(struct ice_rx_ring *rx_ring);
|
2018-03-20 07:58:14 -07:00
|
|
|
int ice_napi_poll(struct napi_struct *napi, int budget);
|
2020-05-11 18:01:42 -07:00
|
|
|
int
|
|
|
|
ice_prgm_fdir_fltr(struct ice_vsi *vsi, struct ice_fltr_desc *fdir_desc,
|
|
|
|
u8 *raw_packet);
|
2021-08-19 13:59:58 +02:00
|
|
|
int ice_clean_rx_irq(struct ice_rx_ring *rx_ring, int budget);
|
|
|
|
void ice_clean_ctrl_tx_irq(struct ice_tx_ring *tx_ring);
|
2018-03-20 07:58:10 -07:00
|
|
|
#endif /* _ICE_TXRX_H_ */
|