Thank you Ilya.
The current learn action only supports load(setting properties) and output (where the packet go). The learn action output supports standard ports, OFPP_IN_PORT, OFPP_FLOOD, OFPP_LOCAL and OFPP_ALL. There is such a scenario (pseudo code): INGRESS: match: <5-tuple> actions: learn(match(ip_src=ip_dst,ip_dst=ip_src,tp_src=tp_dst,tp_dst=tp_src,protocol actions:load(...),output:IN_PORT/REG_N_OF_PORT_NUMBER),<other_actions> EGRESS learnt flow: match(<ip_src=ip_dst,ip_dst=ip_src,tp_src=tp_dst,tp_dst=tp_src,protocol> actions: load(...),output:... It will create a reverse packet matching flow from the INGRESS learn action. This learnt flow, after matching, can only perform output actions and cannot enter more pipeline processing. This leads to the fact that the learnt flow matching must be designed as the final stage of the pipeline, otherwise the packets will be discarded by default. If OFPP_TABLE is supported, this can be changed to: INGRESS: match: <5-tuple> actions: learn(match(<ip_src=ip_dst,ip_dst=ip_src,tp_src=tp_dst,tp_dst=tp_src,protocol> actions: load(...),output:OFPP_TABLE) EGRESS learnt flow: match(<ip_src=ip_dst,ip_dst=ip_src,tp_src=tp_dst,tp_dst=tp_src,protocol> actions: load(...), output:TABLE then, packets can goto table=0 again, and we can match register or any valid fields to enter an extra pipeline. I am not quite sure about the impact of the OPENFLOW definition on OVS development, but obviously this learning mechanism does not exist in the OpenFlow definition. This learn action is not related to OPENFLOW, it's an OVS internal action only. For OPENFLOW defined reserved ports, learn action also partially supported (OFPP_IN_PORT, OFPP_FLOOD, OFPP_LOCAL and OFPP_ALL). For more flexible use, I think this OFPP_TABLE number can be added to make the pipeline more flexible. Another idea I have is to add a `goto_table` action to the learn action support list. Do you think it's possible to implement this without referencing by any OPENFLOW/other protocol constraints? If this is acceptable, we can achive the flexible as well. Regards, LIU Yulong ------------------ Original ------------------ From: "Ilya Maximets"; Date: 2024年7月12日(星期五) 晚上7:42 To: "LIU Yulong"; "ovs-dev"; Cc: "i.maximets"; Subject: Re: [ovs-dev] [PATCH] learn: Support learn output with OFPP_TABLE port. On 7/12/24 05:26, LIU Yulong wrote: > The ofport OFPP_TABLE(0xfff9) is defined as perform > actions in flow table. It will send the packet back > to table=0 to do reprocess. Add this port to learn > output action then users can leverage it to do some > flow table re-entry. > > Signed-off-by: LIU Yulong <[email protected]> > --- > lib/learn.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/lib/learn.c b/lib/learn.c > index a62add2fd..68d27307a 100644 > --- a/lib/learn.c > +++ b/lib/learn.c > @@ -167,6 +167,7 @@ learn_execute(const struct ofpact_learn *learn, const struct flow *flow, > if (ofp_to_u16(port) < ofp_to_u16(OFPP_MAX) > || port == OFPP_IN_PORT > || port == OFPP_FLOOD > + || port == OFPP_TABLE > || port == OFPP_LOCAL > || port == OFPP_ALL) { > ofpact_put_OUTPUT(ofpacts)->port = port; Hi. Thanks for the patch! The definition of the OFPP_TABLE in OpenFlow specification allows to use it only in packet-out messages: OFPP_TABLE = 0xfffffff9, /* Submit the packet to the first flow table NB: This destination port can only be used in packet-out messages. */ So, we should not use it for any other purpose. Most of the time it is possible to use learned flows to just set some registers and then you could use those registers in a different table with any types of actions. The 'learn' section of the docs contains a more detailed explanation on how to achieve that: https://docs.openvswitch.org/en/stable/ref/ovs-actions.7/#the-learn-action Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
