Re: [dpdk-dev] [PATCH 1/2] ethdev: add flow action type update as an offload

[Thomas Monjalon <thomas@monjalon.net>]

31/10/2019 10:49, Andrew Rybchenko:
> On 10/28/19 5:00 PM, Ori Kam wrote:
> >> -----Original Message-----
> > From: Andrew Rybchenko <arybchenko@solarflare.com>
> >> On 10/28/19 1:50 PM, Ori Kam wrote:
> >>> Hi Pavan,
> >>>
> >>> Sorry for jumping in late.
> >>>
> >>> I don't understand why we need this feature. If the user didn't set any flow
> >> with MARK
> >>> then the user doesn't need to check it.
> >> There is pretty long discussion on the topic already, please, read [1].
> >>
> >> [1]
> >> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Finbox.dpdk
> >> .org%2Fdev%2F3251fc00-7598-1c4f-fc2a-
> >> 380065f0a435%40solarflare.com%2F&amp;data=02%7C01%7Corika%40mellan
> >> ox.com%7Ce3f779d4b7c44b682d6508d75b9d8688%7Ca652971c7d2e4d9ba6a4
> >> d149256f461b%7C0%7C0%7C637078604439019114&amp;sdata=sYooc%2FQ3C
> >> kUZG3gRFPlZrm8xMfMB9gOWWex5YIkWhMc%3D&amp;reserved=0
> >>
> > Thanks for the link, it was an interesting reading.
> >
> >>> Also it breaks compatibility.
> >> Yes, there is a deprecation notice for it.
> >>
> >>> If my understanding is correct the MARK field is going to be moved to
> >> dynamic field, and this
> >>> will be way to control the use of MARK.
> >> Yes and I think the offload should used to request dynamic
> >> field register. Similar to timestamp in dynamic mbuf examples.
> >> Application requests Rx timestamp offload, PMD registers dynamic
> >> filed.
> >>
> > In general it was decided that there will be no capability for rte_flow API, due to the fact that
> > it is impossible to support all possible combinations. For example a PMD can allow mark on Rx
> > while not supporting it on e-switch (transfer) or on Tx.
> > The only way to validate it is validating a flow. If the flow is validated then the action is supported.
> > This is the exact approach we are implementing with the Meta feature.
> > So as I see it, the logic should be something like this:
> > 1. run devconfigure.
> > 2. allocate mempool
> > 3. setup queues.
> > 4. run rte_flow_validate with mark action.
> > If flow validated register mark in mbuf else don't register.
> > If the PMD needs some special setting for mark he can update the queue when he gets the flow to validate.
> > At this stage the device is not started so any change is allowed.
> 
> I understand why there is capability reporting in rte_flow API when
> it is about rte_flow API itself. The problem appears when rte_flow
> API starts to interact with other functionality.
> Which pattern/actions should application try in order to decide
> if MARK is supported or not.

Why application should decide whether MARK is supported or not?
In my understanding it can be enabled dynamically per flow.

> The right answer is a pattern/action
> which will be really used, but what to do if there are many
> combinations or if these combinations are not know in advance.
> Minimal? But I easily imagine cases when minimal is not supported,
> but more complex real life patterns are supported.
> 
> The main idea behind the offload is as much as you know in advance
> as much you can optimize without overcomplicating drivers and HW.
> 
> In the case of OVS, absence MARK offload would mean that OVS
> should not even try to use partial offload even if it is enabled.
> So, no efforts are required to try to convert flow into pattern and
> validate the flow rule.

That's an interesting feedback.
I would like to understand why OVS cannot adapt its datapath on demand
per port, per queue and per flow?