DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Azarewicz, PiotrX T" <piotrx.t.azarewicz@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: [dpdk-dev] FW: [PATCH v2 1/1] ip_frag: fix creating ipv6 fragment extension header
Date: Wed, 9 Sep 2015 10:47:21 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725836A84A7C@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <1441721267-19142-1-git-send-email-piotrx.t.azarewicz@intel.com>

Hi Piotr,

> -----Original Message-----
> From: Azarewicz, PiotrX T
> Sent: Tuesday, September 08, 2015 3:08 PM
> To: dev@dpdk.org
> Cc: Dumitrescu, Cristian; Ananyev, Konstantin; Azarewicz, PiotrX T
> Subject: [PATCH v2 1/1] ip_frag: fix creating ipv6 fragment extension header
> 
> Previous implementation won't work on every environment. The order of
> allocation of bit-fields within a unit (high-order to low-order or
> low-order to high-order) is implementation-defined.
> Solution: used bytes instead of bit fields.
> 
> v2 changes:
> - remove useless union
> - fix process_ipv6 function (due to remove the union above)
> 
> Signed-off-by: Piotr Azarewicz <piotrx.t.azarewicz@intel.com>
> ---
>  lib/librte_ip_frag/rte_ip_frag.h            |   13 ++-----------
>  lib/librte_ip_frag/rte_ipv6_fragmentation.c |    6 ++----
>  lib/librte_port/rte_port_ras.c              |   10 +++++++---
>  3 files changed, 11 insertions(+), 18 deletions(-)
> 
> diff --git a/lib/librte_ip_frag/rte_ip_frag.h b/lib/librte_ip_frag/rte_ip_frag.h
> index 52f44c9..f3ca566 100644
> --- a/lib/librte_ip_frag/rte_ip_frag.h
> +++ b/lib/librte_ip_frag/rte_ip_frag.h
> @@ -130,17 +130,8 @@ struct rte_ip_frag_tbl {
>  /** IPv6 fragment extension header */
>  struct ipv6_extension_fragment {
>  	uint8_t next_header;            /**< Next header type */
> -	uint8_t reserved1;              /**< Reserved */
> -	union {
> -		struct {
> -			uint16_t frag_offset:13; /**< Offset from the start of the packet */
> -			uint16_t reserved2:2; /**< Reserved */
> -			uint16_t more_frags:1;
> -			/**< 1 if more fragments left, 0 if last fragment */
> -		};
> -		uint16_t frag_data;
> -		/**< union of all fragmentation data */
> -	};
> +	uint8_t reserved;               /**< Reserved */
> +	uint16_t frag_data;             /**< All fragmentation data */
>  	uint32_t id;                    /**< Packet ID */
>  } __attribute__((__packed__));
> 
> diff --git a/lib/librte_ip_frag/rte_ipv6_fragmentation.c b/lib/librte_ip_frag/rte_ipv6_fragmentation.c
> index 0e32aa8..ab62efd 100644
> --- a/lib/librte_ip_frag/rte_ipv6_fragmentation.c
> +++ b/lib/librte_ip_frag/rte_ipv6_fragmentation.c
> @@ -65,10 +65,8 @@ __fill_ipv6hdr_frag(struct ipv6_hdr *dst,
> 
>  	fh = (struct ipv6_extension_fragment *) ++dst;
>  	fh->next_header = src->proto;
> -	fh->reserved1   = 0;
> -	fh->frag_offset = rte_cpu_to_be_16(fofs);
> -	fh->reserved2   = 0;
> -	fh->more_frags  = rte_cpu_to_be_16(mf);
> +	fh->reserved = 0;
> +	fh->frag_data = rte_cpu_to_be_16((fofs & ~IPV6_HDR_FO_MASK) | mf);
>  	fh->id = 0;
>  }
> 
> diff --git a/lib/librte_port/rte_port_ras.c b/lib/librte_port/rte_port_ras.c
> index 6bd0f8c..3dbd5be 100644
> --- a/lib/librte_port/rte_port_ras.c
> +++ b/lib/librte_port/rte_port_ras.c
> @@ -205,6 +205,9 @@ process_ipv4(struct rte_port_ring_writer_ras *p, struct rte_mbuf *pkt)
>  	}
>  }
> 
> +#define MORE_FRAGS(x) ((x) & 0x0001)
> +#define FRAG_OFFSET(x) ((x) >> 3)
> +
>  static void
>  process_ipv6(struct rte_port_ring_writer_ras *p, struct rte_mbuf *pkt)
>  {
> @@ -212,12 +215,13 @@ process_ipv6(struct rte_port_ring_writer_ras *p, struct rte_mbuf *pkt)
>  	struct ipv6_hdr *pkt_hdr = rte_pktmbuf_mtod(pkt, struct ipv6_hdr *);
> 
>  	struct ipv6_extension_fragment *frag_hdr;
> +	uint16_t frag_data = 0;
>  	frag_hdr = rte_ipv6_frag_get_ipv6_fragment_header(pkt_hdr);
> -	uint16_t frag_offset = frag_hdr->frag_offset;
> -	uint16_t frag_flag = frag_hdr->more_frags;
> +	if (frag_hdr != NULL)
> +		frag_data = rte_be_to_cpu_16(frag_hdr->frag_data);
> 
>  	/* If it is a fragmented packet, then try to reassemble */
> -	if ((frag_flag == 0) && (frag_offset == 0))
> +	if ((MORE_FRAGS(frag_data) == 0) && (FRAG_OFFSET(frag_data) == 0))
>  		p->tx_buf[p->tx_buf_count++] = pkt;
>  	else {
>  		struct rte_mbuf *mo;
> --
> 1.7.9.5

When I wrote " provide macros to read/set fragment_offset and more_flags values",
I meant move IPV6_HDR_*macros that are useful from lib/librte_ip_frag/rte_ipv6_fragmentation.c
into rte_ip_frag.h and add new one based on them.
Obviously it seems strange to define some macros in .c file, never use most of them,
and in another .c file use hardcoded values instead of them again.

Something like:

#define RTE_IPV6_HDR_MF_MASK                     1
#define RTE_IPV6_HDR_FO_SHIFT                       3
#define RTE_IPV6_HDR_FO_MASK                       ((1 << IPV6_HDR_FO_SHIFT) - 1))

#define RTE_IPV6_GET_MF(x)                 ((x) & RTE_IPV6_HDR_MF_MASK)
#define RTE_IPV6_GET_FO(x)		((x) >> RTE_IPV6_HDR_FO_SHIFT)

#define RTE_IPV6_FRAG_DATA(fo, mf)	(((fo) & ~RTE_IPV6_HDR_FO_MASK)) | ((mf) & RTE_IPV6_HDR_MF_MASK))

And then use these macros in both .c files.

Actually another note:
+	if ((MORE_FRAGS(frag_data) == 0) && (FRAG_OFFSET(frag_data) == 0))

Why do you need && here?
Why just not:

#define RTE_IPV6_FRAG_USED_MASK		(RTE_IPV6_HDR_MF_MASK | ~RTE_IPV6_HDR_FO_MASK)
...
if ((frag_data  & RTE_IPV6_FRAG_USED_MASK) == 0)
?

Thanks
Konstantin

  parent reply	other threads:[~2015-09-09 10:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-02 14:13 [dpdk-dev] [PATCH " Piotr
2015-09-03 15:23 ` Dumitrescu, Cristian
2015-09-04 15:51 ` Ananyev, Konstantin
2015-09-07 11:21   ` Dumitrescu, Cristian
2015-09-07 11:23     ` Ananyev, Konstantin
2015-09-07 11:24       ` Dumitrescu, Cristian
2015-09-08 14:07 ` [dpdk-dev] [PATCH v2 " Piotr Azarewicz
2015-09-09 10:40   ` Dumitrescu, Cristian
2015-09-09 10:47   ` Ananyev, Konstantin [this message]
2015-09-09 13:39   ` [dpdk-dev] [PATCH v3 " Piotr Azarewicz
2015-09-10  7:09     ` [dpdk-dev] [PATCH v4 " Piotr Azarewicz
2015-09-10  8:35       ` Ananyev, Konstantin
2015-09-10 12:24       ` Dumitrescu, Cristian
2015-10-08 11:24         ` 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=2601191342CEEE43887BDE71AB97725836A84A7C@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=dev@dpdk.org \
    --cc=piotrx.t.azarewicz@intel.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).