patches for DPDK stable branches
 help / color / mirror / Atom feed
From: "John Daley (johndale)" <johndale@cisco.com>
To: Luca Boccassi <bluca@debian.org>
Cc: "stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-stable] [PATCH] net/enic: fix TSO for packets greater than 9208 bytes
Date: Fri, 3 Nov 2017 19:06:18 +0000	[thread overview]
Message-ID: <ac679ad5576b47da92f8ba72cd77e690@XCH-RCD-007.cisco.com> (raw)
In-Reply-To: <1509703215.9111.3.camel@debian.org>



> -----Original Message-----
> From: Luca Boccassi [mailto:bluca@debian.org]
> Sent: Friday, November 03, 2017 3:00 AM
> To: John Daley (johndale) <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
> 
> 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.

My apologies, this version of the fix was not supposed to get out into the wild.
The patch I submitted that was accepted into dpdk-next-net is f12766f72.

> 
> 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.

You are correct, the feature being patched (TSO) did not exist in 16.11 so the patch doesn't apply. It does apply to the 17.05 stable branch. Please apply it there if a 17.05.3 is going to be created. Sorry again for the confusion.
> 
> Thanks!
> 
> --
> Kind regards,
> Luca Boccassi

  reply	other threads:[~2017-11-03 19:06 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
2017-11-03 19:06   ` John Daley (johndale) [this message]
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=ac679ad5576b47da92f8ba72cd77e690@XCH-RCD-007.cisco.com \
    --to=johndale@cisco.com \
    --cc=bluca@debian.org \
    --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).