From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: Ori Kam <orika@mellanox.com>
Cc: nelio.laranjeiro@6wind.com, yskoh@mellanox.com, dev@dpdk.org,
stable@dpdk.org
Subject: Re: [dpdk-stable] [PATCH] net/mlx5: fix number of segment calculation
Date: Fri, 10 Nov 2017 11:06:25 +0100 [thread overview]
Message-ID: <20171110100625.GF24849@6wind.com> (raw)
In-Reply-To: <1510243472-24872-1-git-send-email-orika@mellanox.com>
Hi Ori,
On Thu, Nov 09, 2017 at 06:04:32PM +0200, Ori Kam wrote:
> The CRC size should be taken into consideration when computing
> the number of mbuf segments for packet on the receive path.
> Large packets can be dropped due to extra CRC length.
>
> Fixes: a1366b1a2be3 ("net/mlx5: add reference counter on DPDK Rx queues")
> Cc: stable@dpdk.org
> Cc: nelio.laranjeiro@6wind.com
>
> Signed-off-by: Ori Kam <orika@mellanox.com>
I don't think there's an issue to fix, there's actually a reason it's done
that way, perhaps I'm wrong but let me elaborate.
When applications request CRC to be written to mbuf (more precisely not to
be stripped), its extra 4 bytes are neither part of mbuf->pkt_len nor
mbuf->data_len. It just happens to be written past mbuf data if there's room
for it, where applications knowingly expect it based on how they configured
the PMD. That's the API.
This implies applications also size mbufs accordingly; if they don't provide
room for the CRC, it can't be written. This extra room is assumed to be part
of max_rx_pkt_len. When CRC stripping is requested, they do not have to
provide such room (IBV_WQ_FLAGS_SCATTER_FCS is not set on mlx5 Rx queues).
One problem with your proposal is assuming all segments are consumed
entirely during Rx and max_rx_pkt_len is reached, another segment with zero
data length gets appended just to hold the CRC. Applications may interpret
this as a bug.
Another problem is this doesn't solve the issue when Rx scatter is disabled
although it's no different from when packet data consumes all segments
entirely and there's no room left for the CRC. If it's that important, the
PMD should fail to create the Rx queue in that case as well.
> ---
> drivers/net/mlx5/mlx5_rxq.c | 7 +++++--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_rxq.c b/drivers/net/mlx5/mlx5_rxq.c
> index 6b29aae..701925b 100644
> --- a/drivers/net/mlx5/mlx5_rxq.c
> +++ b/drivers/net/mlx5/mlx5_rxq.c
> @@ -887,6 +887,8 @@ struct mlx5_rxq_ctrl*
> const uint16_t desc_n =
> desc + priv->rx_vec_en * MLX5_VPMD_DESCS_PER_LOOP;
> unsigned int mb_len = rte_pktmbuf_data_room_size(mp);
> + uint8_t crc_size =
> + !!(dev->data->dev_conf.rxmode.hw_strip_crc == 0) << 2;
>
> tmpl = rte_calloc_socket("RXQ", 1,
> sizeof(*tmpl) +
> @@ -900,12 +902,13 @@ struct mlx5_rxq_ctrl*
> /* Enable scattered packets support for this queue if necessary. */
> assert(mb_len >= RTE_PKTMBUF_HEADROOM);
> if (dev->data->dev_conf.rxmode.max_rx_pkt_len <=
> - (mb_len - RTE_PKTMBUF_HEADROOM)) {
> + (mb_len - RTE_PKTMBUF_HEADROOM - crc_size)) {
> tmpl->rxq.sges_n = 0;
> } else if (dev->data->dev_conf.rxmode.enable_scatter) {
> unsigned int size =
> RTE_PKTMBUF_HEADROOM +
> - dev->data->dev_conf.rxmode.max_rx_pkt_len;
> + dev->data->dev_conf.rxmode.max_rx_pkt_len +
> + crc_size;
> unsigned int sges_n;
>
> /*
> --
> 1.7.1
>
--
Adrien Mazarguil
6WIND
next prev parent reply other threads:[~2017-11-10 10:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-09 16:04 Ori Kam
2017-11-09 22:30 ` Yongseok Koh
2017-11-10 10:22 ` Adrien Mazarguil
2017-11-10 21:42 ` Yongseok Koh
2017-11-10 10:06 ` Adrien Mazarguil [this message]
2017-11-10 21:22 ` Yongseok Koh
2017-11-12 7:08 ` Ori Kam
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=20171110100625.GF24849@6wind.com \
--to=adrien.mazarguil@6wind.com \
--cc=dev@dpdk.org \
--cc=nelio.laranjeiro@6wind.com \
--cc=orika@mellanox.com \
--cc=stable@dpdk.org \
--cc=yskoh@mellanox.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).