31/10/2019 10:49, Andrew Rybchenko: > On 10/28/19 5:00 PM, Ori Kam wrote: > >> -----Original Message----- > > From: Andrew Rybchenko <arybche...@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&data=02%7C01%7Corika%40mellan > >> ox.com%7Ce3f779d4b7c44b682d6508d75b9d8688%7Ca652971c7d2e4d9ba6a4 > >> d149256f461b%7C0%7C0%7C637078604439019114&sdata=sYooc%2FQ3C > >> kUZG3gRFPlZrm8xMfMB9gOWWex5YIkWhMc%3D&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?
