From: Nick Child <nnac123@linux.ibm.com>
To: netdev@vger.kernel.org
Cc: bjking1@linux.ibm.com, haren@linux.ibm.com, ricklind@us.ibm.com,
Nick Child <nnac123@linux.ibm.com>
Subject: [PATCH net-next 7/7] ibmvnic: Perform tx CSO during send scrq direct
Date: Thu, 1 Aug 2024 16:23:40 -0500 [thread overview]
Message-ID: <20240801212340.132607-8-nnac123@linux.ibm.com> (raw)
In-Reply-To: <20240801212340.132607-1-nnac123@linux.ibm.com>
During initialization with the vnic server, a bitstring is communicated
to the client regarding header info needed during CSO (See "VNIC
Capabilities" in PAPR). Most of the time, to be safe, vnic server
requests header info for CSO. When header info is needed, multiple TX
descriptors are required per skb; This limits the driver to use
send_subcrq_indirect instead of send_subcrq_direct.
Previously, the vnic server request for header info was ignored. This
allowed the use of send_sub_crq_direct. Transmitions were successful
because the bitstring returned by vnic server is very broad and over
cautionary. It was observed that mlx backing devices could actually
transmit and handle CSO packets without the vnic server receiving
header info (despite the fact that the bitstring requested it).
There was a trust issue: The bitstring was overcautionary. This extra
precaution (requesting header info when the backing device may not use
it) comes at the cost of performance (using direct vs indirect hcalls
has a 30% delta in small packet RR transaction rate). So it has been
requested that the vnic server team tries to ensure that the bitstring
is more exact. In the meantime, disable CSO when it is possible to use
the skb in the send_subcrq_direct path. In other words, calculate the
checksum before handing the packet to FW when the packet is not
segmented and xmit_more is false.
When the bitstring ever specifies that CSO does not require headers
(dependent on VIOS vnic server changes), then this patch should be
removed and replaced with one that investigates the bitstring before
using send_subcrq_direct.
Signed-off-by: Nick Child <nnac123@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 05c0d68c3efa..1990d518f247 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2406,6 +2406,7 @@ static netdev_tx_t ibmvnic_xmit(struct sk_buff *skb, struct net_device *netdev)
unsigned long lpar_rc;
union sub_crq tx_crq;
unsigned int offset;
+ bool use_scrq_send_direct = false;
int num_entries = 1;
unsigned char *dst;
int bufidx = 0;
@@ -2465,6 +2466,18 @@ static netdev_tx_t ibmvnic_xmit(struct sk_buff *skb, struct net_device *netdev)
memset(dst, 0, tx_pool->buf_size);
data_dma_addr = ltb->addr + offset;
+ /* if we are going to send_subcrq_direct this then we need to
+ * update the checksum before copying the data into ltb. Essentially
+ * these packets force disable CSO so that we can guarantee that
+ * FW does not need header info and we can send direct.
+ */
+ if (!skb_is_gso(skb) && !ind_bufp->index && !netdev_xmit_more()) {
+ use_scrq_send_direct = true;
+ if (skb->ip_summed == CHECKSUM_PARTIAL &&
+ skb_checksum_help(skb))
+ use_scrq_send_direct = false;
+ }
+
if (skb_shinfo(skb)->nr_frags) {
int cur, i;
@@ -2546,11 +2559,13 @@ static netdev_tx_t ibmvnic_xmit(struct sk_buff *skb, struct net_device *netdev)
tx_crq.v1.flags1 |= IBMVNIC_TX_LSO;
tx_crq.v1.mss = cpu_to_be16(skb_shinfo(skb)->gso_size);
hdrs += 2;
- } else if (!ind_bufp->index && !netdev_xmit_more()) {
- ind_bufp->indir_arr[0] = tx_crq;
+ } else if (use_scrq_send_direct) {
+ /* See above comment, CSO disabled with direct xmit */
+ tx_crq.v1.flags1 &= ~(IBMVNIC_TX_CHKSUM_OFFLOAD);
ind_bufp->index = 1;
tx_buff->num_entries = 1;
netdev_tx_sent_queue(txq, skb->len);
+ ind_bufp->indir_arr[0] = tx_crq;
lpar_rc = ibmvnic_tx_scrq_flush(adapter, tx_scrq, false);
if (lpar_rc != H_SUCCESS)
goto tx_err;
--
2.43.0
next prev parent reply other threads:[~2024-08-01 21:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 21:23 [PATCH net-next 0/7] ibmvnic RR performance improvements Nick Child
2024-08-01 21:23 ` [PATCH net-next 1/7] ibmvnic: Only replenish rx pool when resources are getting low Nick Child
2024-08-01 21:23 ` [PATCH net-next 2/7] ibmvnic: Use header len helper functions on tx Nick Child
2024-08-01 21:23 ` [PATCH net-next 3/7] ibmvnic: Reduce memcpys in tx descriptor generation Nick Child
2024-08-01 21:23 ` [PATCH net-next 4/7] ibmvnic: Remove duplicate memory barriers in tx Nick Child
2024-08-01 21:23 ` [PATCH net-next 5/7] ibmvnic: Introduce send sub-crq direct Nick Child
2024-08-01 21:23 ` [PATCH net-next 6/7] ibmvnic: Only record tx completed bytes once per handler Nick Child
2024-08-01 21:23 ` Nick Child [this message]
2024-08-03 0:15 ` [PATCH net-next 7/7] ibmvnic: Perform tx CSO during send scrq direct Jakub Kicinski
2024-08-05 13:52 ` Nick Child
2024-08-05 19:09 ` Jakub Kicinski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240801212340.132607-8-nnac123@linux.ibm.com \
--to=nnac123@linux.ibm.com \
--cc=bjking1@linux.ibm.com \
--cc=haren@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=ricklind@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).