kernel/drivers/net/ethernet/sfc/ef100_tx.c, branch linux-6.2.y

sfc (gcc13): synchronize ef100_enqueue_skb()'s return type

2022-11-03T03:38:17Z

ef100_enqueue_skb() generates a valid warning with gcc-13: drivers/net/ethernet/sfc/ef100_tx.c:370:5: error: conflicting types for 'ef100_enqueue_skb' due to enum/integer mismatch; have 'int(struct efx_tx_queue *, struct sk_buff *)' drivers/net/ethernet/sfc/ef100_tx.h:25:13: note: previous declaration of 'ef100_enqueue_skb' with type 'netdev_tx_t(struct efx_tx_queue *, struct sk_buff *)' I.e. the type of the ef100_enqueue_skb()'s return value in the declaration is int, while the definition spells enum netdev_tx_t. Synchronize them to the latter. Cc: Martin Liska Cc: Edward Cree Cc: Martin Habets Signed-off-by: Jiri Slaby (SUSE) Link: https://lore.kernel.org/r/20221031114440.10461-1-jirislaby@kernel.org Signed-off-by: Jakub Kicinski

sfc: support passing a representor to the EF100 TX path

2022-07-22T11:50:06Z

A non-null efv in __ef100_enqueue_skb() indicates that the packet is from that representor, should be transmitted with a suitable option descriptor (to instruct the switch to deliver it to the representee), and should not be accounted to the parent PF's stats or BQL. Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: support GRE TSO on EF100

2020-11-13T23:33:30Z

We can treat SKB_GSO_GRE almost exactly the same as UDP tunnels, except that we don't want to edit the outer UDP len (as there isn't one). For SKB_GSO_GRE_CSUM, we have to use GSO_PARTIAL as the device doesn't support offload of non-UDP outer L4 checksums. Signed-off-by: Edward Cree Signed-off-by: Jakub Kicinski Acked-by: Martin Habets Reviewed-by: Alexander Duyck

sfc: correctly support non-partial GSO_UDP_TUNNEL_CSUM on EF100

2020-11-13T23:33:27Z

By asking the HW for the correct edits, we can make UDP tunnel TSO work without needing GSO_PARTIAL. So don't specify it in our netdev->gso_partial_features. However, retain GSO_PARTIAL support, as this will be used for other protocols later. Signed-off-by: Edward Cree Signed-off-by: Jakub Kicinski Acked-by: Martin Habets Reviewed-by: Alexander Duyck

sfc: only use fixed-id if the skb asks for it

2020-10-31T00:42:53Z

AIUI, the NETIF_F_TSO_MANGLEID flag is a signal to the stack that a driver may _need_ to mangle IDs in order to do TSO, and conversely a signal from the stack that the driver is permitted to do so. Since we support both fixed and incrementing IPIDs, we should rely on the SKB_GSO_FIXEDID flag on a per-skb basis, rather than using the MANGLEID feature to make all TSOs fixed-id. Includes other minor cleanups of ef100_make_tso_desc() coding style. Signed-off-by: Edward Cree Signed-off-by: Jakub Kicinski

sfc: implement encap TSO on EF100

2020-10-31T00:42:53Z

The NIC only needs to know where the headers it has to edit (TCP and inner and outer IPv4) are, which fits GSO_PARTIAL nicely. It also supports non-PARTIAL offload of UDP tunnels, again just needing to be told the outer transport offset so that it can edit the UDP length field. (It's not clear to me whether the stack will ever use the non-PARTIAL version with the netdev feature flags we're setting here.) Signed-off-by: Edward Cree Signed-off-by: Jakub Kicinski

sfc: de-indirect TSO handling

2020-09-12T00:15:22Z

Remove the tx_queue->handle_tso function pointer, and just use tx_queue->tso_version to decide which function to call, thus removing an indirect call from the fast path. Instead of passing a tso_v2 flag to efx_mcdi_tx_init(), set the desired tx_queue->tso_version before calling it. In efx_mcdi_tx_init(), report back failure to obtain a TSOv2 context by setting tx_queue->tso_version to 0, which will cause the TX path to use the GSO-based fallback. Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: remove spurious unreachable return statement

2020-09-11T21:55:14Z

The statement above it already returns, so there is no way to get here. Signed-off-by: Edward Cree Signed-off-by: David S. Miller

sfc: use tx_queue->old_read_count in EF100 TX path

2020-09-05T19:21:40Z

As in the Siena/EF10 case, it minimises cacheline ping-pong between the TX and completion paths. Signed-off-by: Edward Cree Signed-off-by: Jakub Kicinski

sfc: make ef100 xmit_more handling look more like ef10's

2020-09-05T19:21:39Z

This should cause no functional change; merely make there only be one design of xmit_more handling to understand. As with the EF10/Siena version, we set tx_queue->xmit_pending when we queue up a TX, and clear it when we ring the doorbell (in ef100_notify_tx_desc). While we're at it, make ef100_notify_tx_desc static since nothing outside of ef100_tx.c uses it. Signed-off-by: Edward Cree Signed-off-by: Jakub Kicinski