DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ori Kam <orika@nvidia.com>
To: Ferruh Yigit <ferruh.yigit@intel.com>,
	Gregory Etelson <getelson@nvidia.com>,
	Wenzhuo Lu <wenzhuo.lu@intel.com>,
	Beilei Xing <beilei.xing@intel.com>,
	Bernard Iremonger <bernard.iremonger@intel.com>,
	Thomas Monjalon <tmonjalon@nvidia.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: Matan Azrad <matan@nvidia.com>,
	Raslan Darawsheh <rasland@nvidia.com>,
	Jeff Guo <jia.guo@intel.com>, Qi Zhang <qi.z.zhang@intel.com>
Subject: Re: [dpdk-dev] [PATCH] app/testpmd: fix flow rules list after port stop
Date: Wed, 26 Aug 2020 17:34:45 +0000	[thread overview]
Message-ID: <MN2PR12MB428653C570339E13EEC9E9BBD6540@MN2PR12MB4286.namprd12.prod.outlook.com> (raw)
In-Reply-To: <5ef628aa-3acd-7a2d-9271-9048761ac778@intel.com>

Hi Ferruh,

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> 
> On 8/20/2020 9:40 AM, Gregory Etelson wrote:
> > Hello,
> >
> > Is this patch scheduled for merge with dpdk.org ?
> > Please update me.
> >
> > Regards,
> > Gregory
> >
> >> -----Original Message-----
> >> From: Gregory Etelson <getelson@mellanox.com>
> >>
> >> According to current RTE API, port flow rules must not be kept after port
> >> stop.
> 
> Hi Gregory, Ori,
> 
> Can you please point where this is documented?
> 
From: rte_ethdev.h
"Please note that some configuration is not stored between calls to
 rte_eth_dev_stop()/rte_eth_dev_start(). The following configuration will
 be retained:

     - MTU
     - flow control settings
     - receive mode configuration (promiscuous mode, all-multicast mode,
       hardware checksum mode, RSS/VMDQ settings etc.)
     - VLAN filtering configuration
     - default MAC address
     - MAC addresses supplied to MAC address array
     - flow director filtering mode (but not filtering rules)
     - NIC queue statistics mappings"

From my understanding this means that flows should not be stored on device stop.


> >>
> >> Testpmd did not flush port flow rules after `port stop' command was called.
> >> As the result, after the port was restarted, it showed bogus flow rules.
> 
> There are two issues,
> 
> 1) According what I see in the rte_flow documentation, not sure if the "port
> stop" should clear the rules:
> "
> PMDs, not applications, are responsible for maintaining flow rules
> configuration
> when stopping and restarting a port or performing other actions which may
> affect
> them. They can only be destroyed explicitly by applications.
> "
> 
Good catch I think this part should be removed, since it has many issues. The application is the only
one that can be responsible for the rules.

Thinks about the following scenario: application configures 2 queues 0 and 1.
It insert flow with queue action 1.
It stops the port and remove queue 1. What should the PMD do?
What happens if he changed some thing else in configuration that make
the actions invalid?

For those reason (the description in rte_ethdev.h and the above issues with keeping the rules)
we (Mellanox) modified our code to remove the flows in stop function from the device.
This code was inserted to DPDK in 20.05 release.
One more reason is that saving the flows also waste a lot of memory
which is very costly to many applications.


> As I tested with i40e, it keeps the rules after stop/start, cc'ing @Jeff,
> @Beilei & @Qi if this is done intentionally.
> 
> 
> 2) From the perspective of the testers, users of the testpmd. If they are
> testing a complex set of filter rules, stopping and starting the port flushing
> all rules may be troublesome.
> Since there is explicit command to remove a rte_flow rule or to remove them
> all,
> user may prefer to call it when required to delete the rules, instead of this is
> done implicitly in port stop.
> 
> Btw, this is based on PMD should handle the rules on stop/start, we need to
> agree on it first, but even that is not the case, we are in the application
> domain now and we can apply the rules back again in the 'start' if it serves
> better to the user.
> 
First like I said above I think we should agree that it is the application 
responsibility to manage the rules and not the PMD, and first thing to do it
update the rte_flow doc.

Second I agree that we should discuss if test-pmd should keep the rules and reapply them,
but just like for the PMD the user may create invalid configuration, so re-applying the rules
maybe incorrect. 
Currently test-pmd is not build to support large number of rules, unless using a script, and if the user uses a script
he can reuse this script. 



Best,
Ori


  reply	other threads:[~2020-08-26 17:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200810161523.6904-1-getelson@mellanox.com>
2020-08-20  8:40 ` Gregory Etelson
2020-08-25 15:51   ` Ferruh Yigit
2020-08-26 17:34     ` Ori Kam [this message]
2020-09-13 12:12       ` Ori Kam
2020-09-13 14:00         ` Thomas Monjalon
2020-11-17 19:08           ` Gregory Etelson
2020-08-11  6:14 Gregory Etelson
2020-11-24 14:42 ` Ajit Khaparde
2020-11-26 15:41   ` 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=MN2PR12MB428653C570339E13EEC9E9BBD6540@MN2PR12MB4286.namprd12.prod.outlook.com \
    --to=orika@nvidia.com \
    --cc=beilei.xing@intel.com \
    --cc=bernard.iremonger@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=getelson@nvidia.com \
    --cc=jia.guo@intel.com \
    --cc=matan@nvidia.com \
    --cc=qi.z.zhang@intel.com \
    --cc=rasland@nvidia.com \
    --cc=tmonjalon@nvidia.com \
    --cc=wenzhuo.lu@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).