On 29 Jun 2021, at 17:23, Van Haaren, Harry wrote:
>> -----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.
Not sure what you meant the the “always consistent for all datapath threads”?
If you mean all PMDs from the same data-path have the same MFEX function, this
is not true once you run the study mode.
>
> 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
I think the output for the additional PMDs is what we need. I’ve never looked
at the DPCL implementation, so no idea if the number of ports is enough, or we
need the explicit ports, etc.? I’ll let others who reviewed that reply ;)
Thanks Harry for digging into this!
>
> $ 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
