From: Luca Boccassi <bluca@debian.org>
To: John Daley <johndale@cisco.com>, johnda888@gmail.com
Cc: stable@dpdk.org
Subject: Re: [dpdk-stable] [PATCH] net/enic: fix TSO for packets greater than 9208 bytes
Date: Fri, 03 Nov 2017 10:00:15 +0000 [thread overview]
Message-ID: <1509703215.9111.3.camel@debian.org> (raw)
In-Reply-To: <20171102015653.1783-1-johndale@cisco.com>
On Wed, 2017-11-01 at 18:56 -0700, John Daley wrote:
> A check was previously added to drop Tx packets greater than what the
> Nic
> is capable of sending since such packets can freeze the send queue.
> The
> check did not account for TSO packets however, so TSO was limited to
> 9208
> bytes.
>
> Check packet length only for non-TSO packets. Also insure that TSO
> packet
> segment size plus the headers do not exceed what the Nic is capable
> of
> since this also can freeze the send queue.
>
> Use the PKT_TX_TCP_SEG ol_flag instead of m->tso_segsz which is the
> preferred way to check for TSO.
>
> Fixes: ed6e564c214e ("net/enic: fix memory leak with oversized Tx
> packets")
> Cc: stable@dpdk.org
>
> Signed-off-by: John Daley <johndale@cisco.com>
> ---
>
> Note that there is some more work to do on enic TSO- the header
> length is
> calculated by looking at the packet instead of just trusting mbuf tso
> offload header lengths. The 'tx_oversized' stat is used for more than
> just
> oversized packets- it gets rolled into 'oerrors' so doesn't matter
> but the
> name should be changed. Some TSO tunneling support can be added for
> newer
> hardware. These changes will come in the next relase, but hope that
> this
> patch can be accepted in 17.11 because it solves existing customer
> problem.
>
> drivers/net/enic/enic_rxtx.c | 25 +++++++++++++++++++------
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/enic/enic_rxtx.c
> b/drivers/net/enic/enic_rxtx.c
> index a39172f14..e938193b5 100644
> --- a/drivers/net/enic/enic_rxtx.c
> +++ b/drivers/net/enic/enic_rxtx.c
> @@ -546,12 +546,15 @@ uint16_t enic_xmit_pkts(void *tx_queue, struct
> rte_mbuf **tx_pkts,
> uint64_t bus_addr;
> uint8_t offload_mode;
> uint16_t header_len;
> + uint64_t tso;
> + rte_atomic64_t *tx_oversized;
>
> enic_cleanup_wq(enic, wq);
> wq_desc_avail = vnic_wq_desc_avail(wq);
> head_idx = wq->head_idx;
> desc_count = wq->ring.desc_count;
> ol_flags_mask = PKT_TX_VLAN_PKT | PKT_TX_IP_CKSUM |
> PKT_TX_L4_MASK;
> + tx_oversized = &enic->soft_stats.tx_oversized;
>
> nb_pkts = RTE_MIN(nb_pkts, ENIC_TX_XMIT_MAX);
>
> @@ -561,10 +564,12 @@ uint16_t enic_xmit_pkts(void *tx_queue, struct
> rte_mbuf **tx_pkts,
> data_len = tx_pkt->data_len;
> ol_flags = tx_pkt->ol_flags;
> nb_segs = tx_pkt->nb_segs;
> + tso = ol_flags & PKT_TX_TCP_SEG;
>
> - if (pkt_len > ENIC_TX_MAX_PKT_SIZE) {
> + /* drop packet if it's too big to send */
> + if (unlikely(!tso && (pkt_len >
> ENIC_TX_MAX_PKT_SIZE))) {
> rte_pktmbuf_free(tx_pkt);
> - rte_atomic64_inc(&enic-
> >soft_stats.tx_oversized);
> + rte_atomic64_inc(tx_oversized);
> continue;
> }
>
> @@ -587,13 +592,21 @@ uint16_t enic_xmit_pkts(void *tx_queue, struct
> rte_mbuf **tx_pkts,
> offload_mode = WQ_ENET_OFFLOAD_MODE_CSUM;
> header_len = 0;
>
> - if (tx_pkt->tso_segsz) {
> + if (tso) {
> header_len = tso_header_len(tx_pkt);
> - if (header_len) {
> - offload_mode =
> WQ_ENET_OFFLOAD_MODE_TSO;
> - mss = tx_pkt->tso_segsz;
> +
> + /* Drop if non-TCP packet or TSO seg size is
> too big */
> + if (unlikely((header_len == 0) || ((tx_pkt-
> >tso_segsz +
> + header_len) > ENIC_TX_MAX_PKT_SIZE))) {
> + rte_pktmbuf_free(tx_pkt);
> + rte_atomic64_inc(tx_oversized);
> + continue;
> }
> +
> + offload_mode = WQ_ENET_OFFLOAD_MODE_TSO;
> + mss = tx_pkt->tso_segsz;
> }
> +
> if ((ol_flags & ol_flags_mask) && (header_len == 0))
> {
> if (ol_flags & PKT_TX_IP_CKSUM)
> mss |= ENIC_CALC_IP_CKSUM;
Hi,
Has this, or a version of this, been accepted into dpdk/master? I did a
quick search but couldn't find it.
I tried to apply it to dpdk-stable/16.11 but the context is quite
different so it doesn't apply. If you would like it for 16.11.4, after
it's accepted in dpdk/master, please send a reworked version that can
be applied to dpdk-stable/16.11.
Thanks!
--
Kind regards,
Luca Boccassi
next prev parent reply other threads:[~2017-11-03 10:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-02 1:56 John Daley
2017-11-03 10:00 ` Luca Boccassi [this message]
2017-11-03 19:06 ` John Daley (johndale)
2017-11-02 1:59 John Daley
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=1509703215.9111.3.camel@debian.org \
--to=bluca@debian.org \
--cc=johnda888@gmail.com \
--cc=johndale@cisco.com \
--cc=stable@dpdk.org \
/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).