> -----Original Message-----
> From: Eelco Chaudron <echau...@redhat.com>
> Sent: Tuesday, June 29, 2021 2:56 PM
> To: Amber, Kumar <kumar.am...@intel.com>
> Cc: Van Haaren, Harry <harry.van.haa...@intel.com>; d...@openvswitch.org;
> i.maxim...@ovn.org; Flavio Leitner <f...@sysclose.org>
> Subject: Re: [ovs-dev] [v4 01/12] dpif-netdev: Add command line and function
> pointer for miniflow extract
> 
> 
> 
> On 29 Jun 2021, at 13:59, Amber, Kumar wrote:
> 
> > Hi Eelco,
> >
> > Thanks a lot for the comments and my replies are inline.
> >
> 
> <SNIP>
> 
> >>> +        return;
> >>> +    }
> >>> +
> >>> +    /* Add all mfex functions to reply string. */
> >>> +    struct ds reply = DS_EMPTY_INITIALIZER;
> >>> +    ds_put_cstr(&reply, "Available Optimized Miniflow Extracts:\n");
> >>> +    for (uint32_t i = 0; i < count; i++) {
> >>> +        ds_put_format(&reply, "  %s (available: %s)\n",
> >>> +                      mfex_impls[i].name, mfex_impls[i].available ?
> >>> +                      "True" : "False");
> >>> +    }
> >>> +    unixctl_command_reply(conn, ds_cstr(&reply));
> >>> +    ds_destroy(&reply);
> >>
> >> I think this command must output the currently configured values for all
> >> data paths, or else there is no easy way to see the current setting.
> >>
> >
> > We are planning to do a separate patch for implementing the same for DPIF,
> > MFEX adnd DPCLS.
> >
> 
> If you do, please do it ASAP, as I think this feature should not get in 
> without being
> able to see in the field what the actual configuration is.

Hi Eelco,
 
OK it seems that there's a lot of focus around visibility of implementation 
used here.
That's good and makes sense, lets focus to get that improved.
 
So moving forward, how about the below output for each command?
(Note, I had a quick chat with Amber & Cian over IM here to get to the below!)
 
The mapping is not always very obvious, as e.g. DPCLS ports can be re-assigned 
between PMD threads.
(Note the implementation of DPCLS might be a bit tricky, as specialized 
subtable searches
aren't externally exposed. I'm confident we'll find a solution.)
 
DPIF and MFEX are enabled per-PMD thread, and are always consistent for all 
datapath threads.
 
Today's commands have very similar output, now with (name: value) data points 
added.
Example for DPIF:   (pmds: 15,16)  means pmd threads 15 and 16 are running that 
impl.
 
Thoughts on the below commands, and added info?  Regards, -Harry
 
 
$ ovs-appctl dpif-netdev/subtable-lookup-prio-get
Available lookup functions (priority : name)
  0 : autovalidator (ports: none)
  1 : generic (ports: none)
  3 : avx512_gather (ports: 2)     # number of DPCLS ports using this impl
 
$ ovs-appctl dpif-netdev/dpif-set-impl
Available DPIF impls:
  dpif_scalar (pmds: 15,16)        # PMD thread ids using this DPIF impl
  dpif_avx512 (pmds: none)
 
$ ovs-appctl  dpif-netdev/miniflow-parser-get
Available Optimized Miniflow Extracts:
  autovalidator (available: True, pmds: none)
  disable (available: True, pmds: none)
  study (available: True, pmds: none)
  avx512_vbmi_ipv4_udp (available: True, pmds: 15,16)         # PMD thread ids 
using this MFEX impl
. <other mfex impls here>

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to