From: Olivier MATZ <olivier.matz@6wind.com>
To: chunmei Liu <chunmei.liu@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] fix ceph async messenger runtime bug based on spdk/dpdk
Date: Thu, 14 Dec 2017 10:24:41 +0100 [thread overview]
Message-ID: <20171214092440.b6gmpmmu734lotmy@platinum> (raw)
In-Reply-To: <1513208695-65016-1-git-send-email-chunmei.liu@intel.com>
Hi Chunmei,
On Wed, Dec 13, 2017 at 03:44:55PM -0800, chunmei Liu wrote:
> From: chunmei <chunmei.liu@intel.com>
>
> ceph async messenger has some run time error with this dpdk library,
> 1) need set rxm->next= null at end of packet since not init it to null
> when allocate a buffer other wise rte_mbuf_sanity_check will report error.
> 2) when check the size, can't calculate mbuf_data_room_size
> because async messenger dpdk will allocate this part later
> not at create mempool.
>
> Signed-off-by: chunmei Liu <chunmei.liu@intel.com>
> ---
> drivers/net/ixgbe/ixgbe_rxtx.c | 3 ++-
> lib/librte_mbuf/rte_mbuf.c | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c
> index 1e07895..918946b 100644
> --- a/drivers/net/ixgbe/ixgbe_rxtx.c
> +++ b/drivers/net/ixgbe/ixgbe_rxtx.c
> @@ -2190,7 +2190,8 @@ ixgbe_recv_pkts_lro(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts,
> rxm->next = next_rxe->mbuf;
> next_sc_entry->fbuf = first_seg;
> goto next_desc;
> - }
> + } else
> + rxm->next = NULL;
>
> /* Initialize the first mbuf of the returned packet */
> ixgbe_fill_cluster_head_buf(first_seg, &rxd, rxq, staterr);
> diff --git a/lib/librte_mbuf/rte_mbuf.c b/lib/librte_mbuf/rte_mbuf.c
> index 0e3e36a..c01da19 100644
> --- a/lib/librte_mbuf/rte_mbuf.c
> +++ b/lib/librte_mbuf/rte_mbuf.c
> @@ -102,7 +102,6 @@ rte_pktmbuf_pool_init(struct rte_mempool *mp, void *opaque_arg)
> }
>
> RTE_ASSERT(mp->elt_size >= sizeof(struct rte_mbuf) +
> - user_mbp_priv->mbuf_data_room_size +
> user_mbp_priv->mbuf_priv_size);
>
> mbp_priv = rte_mempool_get_priv(mp);
I don't see the point here.
Many parts of dpdk rely on this code without issue. I enabled the
asserts and see no issue with testpmd. Can you give more details?
> @@ -233,6 +232,8 @@ rte_mbuf_sanity_check(const struct rte_mbuf *m, int is_header)
> }
> if (nb_segs != 0)
> rte_panic("bad nb_segs\n");
> + if (m_seg != NULL)
> + rte_panic("bad m_seg\n");
> }
A similar check was recently sumbitted in another patch. Please see:
https://dpdk.org/dev/patchwork/patch/32057/
next prev parent reply other threads:[~2017-12-14 9:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-13 23:44 chunmei Liu
2017-12-14 7:47 ` Thomas Monjalon
2017-12-14 9:24 ` Olivier MATZ [this message]
2017-12-14 11:54 ` Ananyev, Konstantin
-- strict thread matches above, loose matches on Subject: below --
2017-12-13 23:40 chunmei Liu
2017-12-13 19:32 chunmei Liu
2017-12-13 21:18 ` Thomas Monjalon
2017-12-13 21:31 ` Stephen Hemminger
2017-12-13 22:34 ` Liu, Chunmei
2017-12-13 22:46 ` Liu, Chunmei
2017-12-13 22:51 ` Stephen Hemminger
2017-12-13 19:28 chunmei Liu
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=20171214092440.b6gmpmmu734lotmy@platinum \
--to=olivier.matz@6wind.com \
--cc=chunmei.liu@intel.com \
--cc=dev@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).