On 3/16/22 14:56, Eli Britstein wrote:
> 
> 
>> -----Original Message-----
>> From: Ilya Maximets <[email protected]>
>> Sent: Wednesday, March 16, 2022 2:43 PM
>> To: Eli Britstein <[email protected]>; [email protected]; Emma Finn
>> <[email protected]>
>> Cc: [email protected]; Ian Stokes <[email protected]>
>> Subject: Re: [ovs-dev] [PATCH V4 1/2] netdev-offload-dpdk: Use has_vlan
>> match attribute
>>
>> External email: Use caution opening links or attachments
>>
>>
>> On 2/7/22 17:56, Eli Britstein via dev wrote:
>>> DPDK 20.11 introduced an ability to specify existance/non-existance of
>>> VLAN tag by [1].
>>> Use this attribute.
>>>
>>> [1]: 09315fc83861 ("ethdev: add VLAN attributes to ethernet and VLAN
>>> items")
>>
>> Hi, Eli.  I'm afraid we still can't use the 'has_vlan' item until there are 
>> drivers
>> that silently ignore it.  And, unfortunately, there are may of them.  I 
>> created
>> a DPDK bug for that issue:
> AFAIU, the problem is not about drivers silently ignoring, but with drivers 
> that fail validation when using this flag.
> If a driver silently ignores, the same behavior as if not using this flag at 
> all.

I believe that i40e driver silently ignores the field, but it was
reported that offloading is broken with that driver for some reason.

Emma, Ian, could you, please, give more information on what exactly
happens with i40e driver if this patch set applied?

If the validation actually fails, I don't see a problem with applying
the patch set, because correctness is more important.  But if there
are drivers that accept the flow, but ignores the flag, we are getting
into "what is more broken?" territory, so it might be OK to get the
patches anyway, I'm not sure.  This part we need to discuss, but we
need more information, as what exactly is happening with the i40e driver.

>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
>> .dpdk.org%2Fshow_bug.cgi%3Fid%3D958&amp;data=04%7C01%7Celibr%40
>> nvidia.com%7C27fe1d1dcfdc4bf4a2f708da074a8809%7C43083d15727340c1
>> b7db39efd9ccc17a%7C0%7C0%7C637830314377416526%7CUnknown%7CT
>> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC
>> JXVCI6Mn0%3D%7C3000&amp;sdata=y1C4%2BFZ5kv6tYsV%2B5muxyuP86X
>> S24LQPx5Nx4nGzPuc%3D&amp;reserved=0
>> And sent a patch to mark drivers with partial support, as Thomas
>> suggested:
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>> hes.dpdk.org%2Fproject%2Fdpdk%2Fpatch%2F20220316120157.390311-1-
>> i.maximets%40ovn.org%2F&amp;data=04%7C01%7Celibr%40nvidia.com%7
>> C27fe1d1dcfdc4bf4a2f708da074a8809%7C43083d15727340c1b7db39efd9cc
>> c17a%7C0%7C0%7C637830314377416526%7CUnknown%7CTWFpbGZsb3d8
>> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3
>> D%7C3000&amp;sdata=ZuUeoPofJpGQxWaIbYnpO7dehehFkVymJ%2Btx5Dr3
>> fC8%3D&amp;reserved=0
>>
>> Is there a way to fix the issue without using the 'has_vlan' field?
> I don't think so. The problem is a missing match, so packets hit a wrong 
> offloaded flow instead of miss and creating a correct flow.

OK.

>>
>> Emma, you said that you will ask about support in i40e driver.
>> Is there any progress on that front?
>>
>> Best regards, Ilya Maximets.

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to