[dpdk-dev] [RFC v2 1/5] ether: add flow action to redirect packet in a switch domain

[Zhang, Qi Z]

Hi Alex

> -----Original Message-----
> From: Alex Rosenbaum [mailto:rosenbaumalex at gmail.com]
> Sent: Thursday, December 21, 2017 8:37 PM
> To: Zhang, Qi Z <qi.z.zhang at intel.com>
> Cc: adrien.mazarguil at 6wind.com; DPDK <dev at dpdk.org>; Doherty, Declan
> <declan.doherty at intel.com>
> Subject: Re: [dpdk-dev] [RFC v2 1/5] ether: add flow action to redirect packet
> in a switch domain
> 
> On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang <qi.z.zhang at intel.com> wrote:
> > Add action RTE_FLOW_ACTION_TYPE_SWITCH_PORT, it can be used to
> > redirect
> 
> I guess the word "SWITCH" should be remove from commit message. you
> don't use it later in the patch.

Yes, it should be corrected.
> 
> 
> >
> > +Action: ``PORT``
> > +^^^^^^^^^^^^^^^^
> > +
> > +Redirect packets to an interface that connect to the same switch domain.
> > +
> > +The destination should be managed by a rte_ethdev instance, port_id
> > +is the identification of the destination. A typical use case is to
> > +define a flow that redirect packet to an interface that managed by a
> > +Port Representor.
> 
> 
> A verbs would be better suited for an ACTION_TYPE. while ".._TYPE_PORT" is
> a nous.
> Probably ".._TYPE_REDIRECT" would better fit here.
> See man tc-mirred as referance:
> http://man7.org/linux/man-pages/man8/tc-mirred.8.html

I agree it will be better to use verbs for action, so we can have TYPE_REDIRECT_TO_PORT/VF/PF...,
But since we already have ACTION_TYPE_VF, ACTION_TYPE_PF ...
Maybe it's better just to follow the same pattern?

> 
> Do we want to distinguish between different destination type?
> The target might be a port (port_id) or potencial other destinations/queue.
> So maybe use ".._TYPE_REDIRECT_TO_PORT"?
> 
> Anyway, I think you should remove the "same switch domain" from docs
> since there is no switch domain yet in DPDK.
> Lets let the PMD decided if this sucessed or fails, based on the target type
> and other HW limitations. Not just based on switch domain.

Yes, it's not necessary to be specific here, the new action is just add the semantic
to support packet redirect between port that managed by etherdevs, device driver
can figure out the way or just reject it.
I will capture this in v3.
> 
> PS: I agree switch domain needs to be introduced. I don't think port
> representor is the correct direction.

OK, thanks for your sharing, I think this can be discussed more on Port Representor mail list

> 
> Alex

Thanks
Qi