All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "stable@dpdk.org" <stable@dpdk.org>,
	"Hall, Ryan E" <ryan.e.hall@intel.com>,
	"Gutkin, Alexander V" <alexander.v.gutkin@intel.com>
Subject: Re: [PATCH v2 2/2] ip_frag: use key length for key comparision
Date: Tue, 6 Nov 2018 11:41:10 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB9772580103069633@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <d93bfd0d-b02b-bb57-18c4-75c514606cbf@intel.com>



> -----Original Message-----
> From: Burakov, Anatoly
> Sent: Tuesday, November 6, 2018 10:54 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; dev@dpdk.org
> Cc: stable@dpdk.org; Hall, Ryan E <ryan.e.hall@intel.com>; Gutkin, Alexander V <alexander.v.gutkin@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v2 2/2] ip_frag: use key length for key comparision
> 
> On 05-Nov-18 12:18 PM, Konstantin Ananyev wrote:
> > Right now reassembly code relies on src_dst[] being all zeroes to
> > determine is it  free/occupied entry in the fragments table.
> > This is suboptimal and error prone - user can crash DPDK ip_reassembly
> > app by something like the following scapy script:
> > x=Ether(src=...,dst=...)/IP(dst='0.0.0.0',src='0.0.0.0',id=0)/('X'*1000)
> > frags=fragment(x, fragsize=500)
> > sendp(frags, iface=...)
> > To overcome that issue and reduce overhead of
> > 'key invalidate'  and 'key is empty' operations -
> > add key_len into keys comparision procedure.
> >
> > Fixes: 4f1a8f633862 ("ip_frag: add IPv6 reassembly")
> > Cc: stable@dpdk.org
> >
> > Reported-by: Ryan E Hall <ryan.e.hall@intel.com>
> > Reported-by: Alexander V Gutkin <alexander.v.gutkin@intel.com>
> > Signed-off-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
> > ---
> 
> 
> 
> > @@ -44,9 +44,17 @@ struct ip_frag {
> >
> >   /** @internal <src addr, dst_addr, id> to uniquely identify fragmented datagram. */
> >   struct ip_frag_key {
> > -	uint64_t src_dst[4];      /**< src address, first 8 bytes used for IPv4 */
> > -	uint32_t id;           /**< dst address */
> > -	uint32_t key_len;      /**< src/dst key length */
> > +	uint64_t src_dst[4];
> > +	/**< src and dst address, only first 8 bytes used for IPv4 */
> > +	RTE_STD_C11
> > +	union {
> > +		uint64_t id_key_len; /**< combined for easy fetch */
> > +		__extension__
> > +		struct {
> > +			uint32_t id;       /**< packet id */
> > +			uint32_t key_len;  /**< src/dst key length */
> > +		};
> > +	};
> >   };
> 
> Would that break ABI?

No, size and layout of the structure  remains the same.
Konstantin

      reply	other threads:[~2018-11-06 11:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-05 10:26 [PATCH 0/2] ip_frag: two fixes in reassembly code Konstantin Ananyev
2018-11-05 10:26 ` [PATCH 1/2] ip_frag: check fragment length of incoming packet Konstantin Ananyev
2018-11-05 11:37   ` [dpdk-stable] " Thomas Monjalon
2018-11-05 10:26 ` [PATCH 2/2] ip_frag: use key length for key comparision Konstantin Ananyev
2018-11-05 12:11 ` [PATCH v2 0/2] ip_frag: two fixes in reassembly code Konstantin Ananyev
2018-11-05 12:11 ` [PATCH v2 1/2] ip_frag: check fragment length of incoming packet Konstantin Ananyev
2018-11-05 12:11 ` [PATCH 2/2] ip_frag: use key length for key comparision Konstantin Ananyev
2018-11-05 12:18 ` [PATCH v2 0/2] ip_frag: two fixes in reassembly code Konstantin Ananyev
2018-11-06  0:58   ` Thomas Monjalon
2018-11-05 12:18 ` [PATCH v2 1/2] ip_frag: check fragment length of incoming packet Konstantin Ananyev
2018-11-05 12:18 ` [PATCH v2 2/2] ip_frag: use key length for key comparision Konstantin Ananyev
2018-11-06 10:53   ` Burakov, Anatoly
2018-11-06 11:41     ` Ananyev, Konstantin [this message]

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=2601191342CEEE43887BDE71AB9772580103069633@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=alexander.v.gutkin@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=ryan.e.hall@intel.com \
    --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 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.