All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Legacy, Allain" <Allain.Legacy@windriver.com>
To: "Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>
Cc: "Adrien Mazarguil (adrien.mazarguil@6wind.com)"
	<adrien.mazarguil@6wind.com>, "dev@dpdk.org" <dev@dpdk.org>,
	"Peters, Matt" <Matt.Peters@windriver.com>
Subject: Re: mlx5 flow create/destroy behaviour
Date: Tue, 28 Mar 2017 16:16:08 +0000	[thread overview]
Message-ID: <70A7408C6E1BFB41B192A929744D8523968F92EF@ALA-MBC.corp.ad.wrs.com> (raw)
In-Reply-To: <20170328153602.GC16796@autoinstall.dev.6wind.com>

> -----Original Message-----
> From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> Sent: Tuesday, March 28, 2017 11:36 AM
<..> 
> If I understand correctly, your application is adding 500 rules like:
> 
>  flow create 0 ingress pattern eth src is <smac> dst is <dmac> / vlan vid is
> <vid> / end action mark id is <id> / queue index 0 / end
>

Almost... the only difference is that the ETH pattern also checks for type=0x8100

> > Once the flows are setup, the application then checks that ingress
> > packets are properly marked with the intended unique integer specified
> > in the MARK action.
> 
> It is sending packets to verify this?

The traffic generator continues to send packets during the test.   Once all flow rules have been created the application expects further ingress packets will be marked with the unique ID.

 
> > When I run this test after the NIC has been reset there are no issues.
> 
> What do you mean by "reset"?

The DPDK test application is quit and restarted therefore the NIC is re-probed, configured, started, etc.   Seems like this is cleaning up whatever problem is resident in the NIC that is causing the new flow rules to not work properly. 

 
> In mlx5 PMD rte_flow_destroy() always returns success as the destruction
> should never fail.
> Can you compile in debug mode (by setting
> CONFIG_RTE_LIBRTE_MLX5_DEBUG to "y")?  Then you should have as many
> print for the creation rules than the destroyed ones.
 
I can give that a try.  

  reply	other threads:[~2017-03-28 16:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-28 12:42 mlx5 flow create/destroy behaviour Legacy, Allain
2017-03-28 15:36 ` Nélio Laranjeiro
2017-03-28 16:16   ` Legacy, Allain [this message]
2017-03-29  9:45     ` Nélio Laranjeiro
2017-03-29 12:29       ` Legacy, Allain
2017-03-30 13:03         ` Nélio Laranjeiro
2017-03-30 16:53           ` Legacy, Allain
2017-03-31  8:34             ` Nélio Laranjeiro
2017-03-31 13:16               ` Legacy, Allain
2017-03-31 13:34                 ` Nélio Laranjeiro

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=70A7408C6E1BFB41B192A929744D8523968F92EF@ALA-MBC.corp.ad.wrs.com \
    --to=allain.legacy@windriver.com \
    --cc=Matt.Peters@windriver.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --cc=nelio.laranjeiro@6wind.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 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.