On Fri, Dec 2, 2022 at 8:18 PM , Eelco Chaudron wrote: > > On 30 Nov 2022, at 4:36, Tianyu Yuan wrote: > > > On Mon, Nov 29, 2022 at 8:35 PM , Eelco Chaudron wrote: > >> > >> On 28 Nov 2022, at 14:33, Marcelo Leitner wrote: > >> > >>> On Mon, Nov 28, 2022 at 02:17:40PM +0100, Eelco Chaudron wrote: > >>>> > >>>> > >>>> On 28 Nov 2022, at 14:11, Marcelo Leitner wrote: > >>>> > >>>>> On Mon, Nov 28, 2022 at 07:11:05AM +0000, Tianyu Yuan wrote: > >>> ... > >>>>>> > >>>>>> Furthermore, I think the current stats for each action mentioned > >>>>>> in > >>>>>> 2) cannot represent the real hw stats and this is why [ RFC > >>>>>> net-next v2 0/2] (net: flow_offload: add support for per action > >>>>>> hw stats) > >> will come up. > >>>>> > >>>>> Exactly. Then, when this patchset (or similar) come up, it won't > >>>>> update all actions with the same stats anymore. It will require a > >>>>> set of stats from hw for the gact with PIPE action here. But if > >>>>> drivers are ignoring this action, they can't have specific stats > >>>>> for it. Or am I missing something? > >>>>> > >>>>> So it is better for the drivers to reject the whole flow instead > >>>>> of simply ignoring it, and let vswitchd probe if it should or > >>>>> should not use this action. > >>>> > >>>> Please note that OVS does not probe features per interface, but > >>>> does it > >> per datapath. So if it’s supported in pipe in tc software, we will > >> use it. If the driver rejects it, we will probably end up with the tc > >> software > rule only. > >>> > >>> Ah right. I remember it will pick 1 interface for testing and use > >>> those results everywhere, which then I don't know if it may or may > >>> not be a representor port or not. Anyhow, then it should use > >>> skip_sw, to try to probe for the offloading part. Otherwise I'm > >>> afraid tc sw will always accept this flow and trick the probing, yes. > >> > >> Well, it depends on how you look at it. In theory, we should be > >> hardware agnostic, meaning what if you have different hardware in > >> your system? OVS only supports global offload enablement. > >> > >> Tianyu how are you planning to support this from the OVS side? How > >> would you probe kernel and/or hardware support for this change? > > > > Currently in the test demo, I just extend gact with PIPE (previously > > only SHOT as default and GOTO_CHAIN when chain exists), and then put > > such a gact with PIPE at the first place of each filter which will be > > transacted > with kernel tc. > > > > About the tc sw datapath mentioned, we don't have to make changes > > because gact with PIPE has already been supported in current tc > > implementation and it could act like a 'counter' And for the hardware > > we just need to ignore this PIPE and the stats of this action will still be > updated in kernel side and sent to userspace. > > I know it’s supported now, but if we implement it, it might fail in existing > environments. So from an OVS userspace perspective, you need to > implement something like:
I've got your point now, sorry for my misunderstanding previously. > > - Probe the kernel to see if this patch is applied, if not use the old method > so > we do not break existing deployments when upgrading OVS but not the > kernel. > - If we do have this newer kernel, do we assume all drivers that worked > before, now also work? > - If this is not the case, how will you determine what approach to use? We > do not have a per-interface layer, but a per-datapath one, i.e. the kernel. We > do not know at initialization time what NICs will be added later and we can > not decide on the strategy to use. > > Thought? Maybe this should be discussed outside of the netdev mailing list, > but what I want to highlight is that there should be a runtime way to > determine if this patch is applied to the kernel (without using any actual hw > driver). I agree that whether the patch is applied in kernel should be checked at runtime rather than compiling (for the demo I made this check inacinlude.m4). I think I need some time to investigate how to implement it. We may discuss it later in an OVS mailing list. Thanks, Tianyu > > //Eelco > > > I agree with that the unsupported actions should be rejected by > > drivers, so may another approach could work without ignoring PIPE in > > all the related drivers, that we directly make put the flower stats > > from driver into the socket which is used to transact with userspace and > userspace(e.g. OVS) update the flow stats using this stats instead of the > parsing the action stats. How do you think of this? _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
