Hi Yuanhan, This will not break our PMD. I think PMDs should be able to handle rss_conf == NULL and then failover to default or initially set rss_conf.
Finn >-----Original Message----- >From: Yuanhan Liu [mailto:y...@fridaylinux.org] >Sent: 29. januar 2018 07:59 >To: Stokes, Ian <ian.sto...@intel.com> >Cc: d...@openvswitch.org; Finn Christensen <f...@napatech.com>; Darrell Ball ><db...@vmware.com>; Chandran, Sugesh <sugesh.chand...@intel.com>; >Simon Horman <simon.hor...@netronome.com> >Subject: Re: [PATCH v5 1/5] dpif-netdev: associate flow with a mark id > >On Fri, Jan 26, 2018 at 04:19:30PM +0800, Yuanhan Liu wrote: >> > > +static bool >> > > +flow_mark_has_no_ref(uint32_t mark) { >> > > + struct dp_netdev_flow *flow; >> > > + >> > >> > Maybe I'm missing something below, but I expected a hash to be >computed for mark before being called with CMAP_FOR_EACH_WITH_HASH? >> >> I treat "mark" as the hash, as it's with the same type of "hash" and >> it's uniq. But you are probably right, it might be better to get the >> hash by "hash_int". Will fix it. > >Oops, I forgot to do the coressponding change for mark_to_flow find. Thus, >the partial offload is completely skiped, as retrieving the flow from mark >would always fail (returing NULL). > >The reason I missed it, while I was testing v6, is I found the flow creation is >failed. I don't really change anything between v5 and v6 and when I was back >to v5, I also met same issue. I then thought it might be introduced by the >OFED or firmware change I have done (for switching to other projects). >I then thought it's something I could figure out laterly. Thus, v6 was sent out >basically just with a build test. > >I then figured out today that the flow creation failure is introduced by a MLX5 >PMD driver change in DPDK v17.11. It looks like a bug to me. And there are 2 >solutions for that: > >- fix it in MLX5 PMD (if it's a bug); I was talking to the author made > such change. >- set rss_conf to NULL, which will let DPDK to follow the one OVS-DPDK > has set in the beginning. > >I chose 2, sicne option 1 won't change the fact that it won't work with DPDK >v17.11. > >And Finn, I probably need your help to verify that option 2 won't break Napa >PMD drivers. > >I will send v7 soon. Please help review. > >Thanks. > > --yliu _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
