All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jean-Mickael Guerin <jean-mickael.guerin-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
To: Konstantin Ananyev
	<konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org
Subject: Re: [RFC PATCH] ixgbe: ixgbe_recv_pkts_vec shouldn't override mbuf buffer length
Date: Fri, 05 Dec 2014 17:59:02 +0100	[thread overview]
Message-ID: <5481E456.1050001@6wind.com> (raw)
In-Reply-To: <1417792834-20590-1-git-send-email-konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>

On 05/12/2014 16:20, Konstantin Ananyev wrote:
> That's an alternative way to fix the problem described in the patch:
> http://dpdk.org/ml/archives/dev/2014-December/009394.html.
> The main difference is:
> - move buf_len fields out of rearm_data marker.
> - make ixgbe_recv_pkts_vec() not touch buf_len field at all
> (as all other RX functions behave).
>
> Signed-off-by: Konstantin Ananyev <konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> ---
>   lib/librte_mbuf/rte_mbuf.h            |  7 +++++--
>   lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c | 20 +++++++++++++++-----
>   2 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 2e5fce5..bb88318 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -179,6 +179,8 @@ const char *rte_get_tx_ol_flag_name(uint64_t mask);
>   typedef void    *MARKER[0];   /**< generic marker for a point in a structure */
>   typedef uint64_t MARKER64[0]; /**< marker that allows us to overwrite 8 bytes
>                                  * with a single assignment */
> +typedef uint8_t MARKER8[0];   /**< generic marker with 1B alignment */
> +
>   /**
>    * The generic rte_mbuf, containing a packet mbuf.
>    */
> @@ -188,9 +190,10 @@ struct rte_mbuf {
>   	void *buf_addr;           /**< Virtual address of segment buffer. */
>   	phys_addr_t buf_physaddr; /**< Physical address of segment buffer. */
>
> -	/* next 8 bytes are initialised on RX descriptor rearm */
> -	MARKER64 rearm_data;
>   	uint16_t buf_len;         /**< Length of segment buffer. */
> +
> +	/* next 6 bytes are initialised on RX descriptor rearm */
> +	MARKER8 rearm_data;
>   	uint16_t data_off;
>
>   	/**
> diff --git a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
> index 579bc46..d5fc0cc 100644
> --- a/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
> +++ b/lib/librte_pmd_ixgbe/ixgbe_rxtx_vec.c
> @@ -79,13 +79,22 @@ ixgbe_rxq_rearm(struct igb_rx_queue *rxq)
>   	/* Initialize the mbufs in vector, process 2 mbufs in one loop */
>   	for (i = 0; i < RTE_IXGBE_RXQ_REARM_THRESH; i += 2, rxep += 2) {
>   		__m128i vaddr0, vaddr1;
> +		uintptr_t p0, p1;
>
>   		mb0 = rxep[0].mbuf;
>   		mb1 = rxep[1].mbuf;
>
> -		/* flush mbuf with pkt template */
> -		mb0->rearm_data[0] = rxq->mbuf_initializer;
> -		mb1->rearm_data[0] = rxq->mbuf_initializer;
> +		/*
> +		 * Flush mbuf with pkt template.
> +		 * Data to be rearmed is 6 bytes long.
> +		 * Though, RX will overwrite ol_flags that are coming next
> +		 * anyway. So overwrite whole 8 bytes with one load:
> +		 * 6 bytes of rearm_data plus first 2 bytes of ol_flags.
> +		 */
> +		p0 = (uintptr_t)&mb0->rearm_data;
> +		*(uint64_t *)p0 = rxq->mbuf_initializer;
> +		p1 = (uintptr_t)&mb1->rearm_data;
> +		*(uint64_t *)p1 = rxq->mbuf_initializer;
>
>   		/* load buf_addr(lo 64bit) and buf_physaddr(hi 64bit) */
>   		vaddr0 = _mm_loadu_si128((__m128i *)&(mb0->buf_addr));
> @@ -732,14 +741,15 @@ static struct ixgbe_txq_ops vec_txq_ops = {
>   int
>   ixgbe_rxq_vec_setup(struct igb_rx_queue *rxq)
>   {
> +	uintptr_t p;
>   	struct rte_mbuf mb_def = { .buf_addr = 0 }; /* zeroed mbuf */
>
>   	mb_def.nb_segs = 1;
>   	mb_def.data_off = RTE_PKTMBUF_HEADROOM;
> -	mb_def.buf_len = rxq->mb_pool->elt_size - sizeof(struct rte_mbuf);
>   	mb_def.port = rxq->port_id;
>   	rte_mbuf_refcnt_set(&mb_def, 1);
> -	rxq->mbuf_initializer = *((uint64_t *)&mb_def.rearm_data);
> +	p = (uintptr_t)&mb_def.rearm_data;
> +	rxq->mbuf_initializer = *(uint64_t *)p;
>   	return 0;
>   }
>
>

The patch introduces writes on unaligned data, but we can assume no 
performance penalty on intel hw, correct?

  parent reply	other threads:[~2014-12-05 16:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-05 15:20 [RFC PATCH] ixgbe: ixgbe_recv_pkts_vec shouldn't override mbuf buffer length Konstantin Ananyev
     [not found] ` <1417792834-20590-1-git-send-email-konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-12-05 16:59   ` Jean-Mickael Guerin [this message]
     [not found]     ` <5481E456.1050001-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2014-12-05 17:07       ` Ananyev, Konstantin
     [not found]         ` <2601191342CEEE43887BDE71AB977258213BD098-kPTMFJFq+rEu0RiL9chJVbfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-05 18:02           ` Thomas Monjalon
2014-12-05 18:03           ` Jean-Mickael Guerin
     [not found]             ` <5481F359.40007-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2014-12-05 22:13               ` Thomas Monjalon

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=5481E456.1050001@6wind.com \
    --to=jean-mickael.guerin-pdr9zngts4eavxtiumwx3w@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.org \
    --cc=konstantin.ananyev-ral2JQCrhuEAvxtiuMwx3w@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.