> -----Original Message-----
> From: Stokes, Ian <ian.sto...@intel.com>
> Sent: Tuesday, August 11, 2020 4:52 AM
> To: Eli Britstein <el...@mellanox.com>; Finn, Emma <emma.f...@intel.com>;
> d...@openvswitch.org; Xing, Beilei <beilei.x...@intel.com>; Guo, Jia
> <jia....@intel.com>
> Cc: i.maxim...@ovn.org
> Subject: RE: [PATCH] netdev-offload-dpdk: Fix for broken ethernet matching
> HWOL for XL710 NIC
>
> > On 8/7/2020 7:55 AM, Eli Britstein wrote:
> > >
> > > On 8/6/2020 8:28 PM, Stokes, Ian wrote:
> > >>> On 8/6/2020 6:17 PM, Emma Finn wrote:
> > >>>> The following 2 commits introduced changes which caused a
> > >>>> regression for XL710 devices and functionality ceases for partial
> > >>>> offload as a result.
> > >>>> 864852a0624a ("netdev-offload-dpdk: Fix Ethernet matching for
> > >>>> type
> > >>>> only.")
> > >>>> a79eae87abe4 ("netdev-offload-dpdk: Remove pre-validate of
> > patterns
> > >>>> function.")
> > >>> OVS is vendor agnostic. That kind of workaround belongs in intel
> > >>> PMD in dpdk, not in OVS.
> > >> Hi Eli,
> > >>
> > >> Yes OVS looks to be vendor agnostic, but this code I believe was
> > >> already in place and working for this usecase. As such it's removal
> > >> introduced a regression from an OVS point of view between the releases.
> > >>
> > >> We have had examples in the past where workarounds are permissible
> > >> if there is a clear path to fixing this in the future on the DPDK
> > >> side (which is what I suggest here) (for example scatter gather
> > >> support for MTUs in the past raised similar issue where we hand to
> > >> handle specific NIC until the next DPDK LTS release).
> > >>
> > >> So my suggestion is to re-instate the original workaround and
> > >> remove its when fixed in the next DPDK LTS which supports the
> > >> change for i40e at the PMD layer or if it's backported to the next
> > >> 19.11 stable release which would be validated for use with OVS.
> > >
> > > Hi,
> > >
> > > There was a bug with this WA.
> > >
> > > Please see
> > > https://patchwork.ozlabs.org/project/openvswitch/patch/1587180266-
> > 28632-1-git-send-email-jackerd...@gmail.com/.
> > >
> > > Is it possible to address it in DPDK instead of reverting in OVS and
> > > later re-reverting?
> > >
> > > Thanks,
> > >
> > > Eli
> > >
> > >>
> > >> I've included the i40e DPDK maintainers here for their thoughts also.
> > >>
> > >> @Beilei/Jia Is this something we can look at to introduce in the
> > >> i40e PMD?
> >
> > Hello,
> >
> > Please take a look at:
> >
> > http://mails.dpdk.org/archives/dev/2020-May/166272.html
> >
> > For MLX it was only an optimization. For i40e something similar may be
> > a workaround for this issue.
>
> Thanks for this Eli, let me sync with Beilei on this.
>
> If it's something we can resolve in the PMD then I think we can add an errata
> or known issue for the 2.14 release (and possibly the 2.13 release as I think
> the
> same issue is present there).
>
> If it was fixed in the future we could then remove the issue notice.
Hi,
According to the OVS patch and mlx DPDK patch, is the requirement to
support rte flow pattern like 'pattern IPv4 / UDP src is 32 / end', no need
to use ''pattern ETH / IPv4 / UDP src is 32 / end '?
please correct me if I'm wrong.
If yes, could you please tell me how OVS adds a flow which doesn’t
include ETH item? I'm not very familiar with OVS, I run some simple
commands before, and find eth will always exist. E.g:
flow_add: ufid:fced09a8-9b8a-420d-9cb6-454ab9bed224
skb_priority(0),skb_mark(0),\
ct_state(-new-est-rel-rpl-inv-trk-snat-dnat),ct_zone(0),ct_mark(0),ct_label(0),recirc_id(0),\
dp_hash(0),in_port(2),packet_type(ns=0,id=0),eth(src=00:e8:ca:11:ba:80,dst=ff:ff:ff:ff:ff:ff),
eth_type(0x0800),ipv4(src=0.0.0.0,dst=255.255.255.255,proto=17,tos=0x10,ttl=128,frag=no),
udp(src=68,dst=67), actions:drop
Thanks,
Beilei
>
> Regards
> Ian
> >
> > Thanks,
> >
> > Eli
> >
> > >>
> > >> Regards
> > >> Ian
> > >>
> > >>>> Fixed by partial reversion of these changes.
> > >>>>
> > >>>> Signed-off-by: Emma Finn<emma.f...@intel.com>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
