[ovs-dev] [v4 01/12] dpif-netdev: Add command line and function pointer for miniflow extract

Van Haaren, Harry harry.van.haaren at intel.com
Tue Jun 29 15:23:12 UTC 2021


> -----Original Message-----
> From: Eelco Chaudron <echaudro at redhat.com>
> Sent: Tuesday, June 29, 2021 2:56 PM
> To: Amber, Kumar <kumar.amber at intel.com>
> Cc: Van Haaren, Harry <harry.van.haaren at intel.com>; dev at openvswitch.org;
> i.maximets at ovn.org; Flavio Leitner <fbl at 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>



More information about the dev mailing list