On 9/19/23 13:57, Robin Jarry wrote:
> Ilya Maximets, Sep 19, 2023 at 13:47:
>> With flexibility of appctl comes absolutely no guarantee for API
>> stability. But as soon as we have structured output, someone will
>> expect it. If we can agree that users cannot rely on the structure
>> of that
Ilya Maximets, Sep 19, 2023 at 13:47:
> With flexibility of appctl comes absolutely no guarantee for API
> stability. But as soon as we have structured output, someone will
> expect it. If we can agree that users cannot rely on the structure
> of that structured output, then it's fine.
On 9/19/23 13:27, Eelco Chaudron wrote:
>
>
> On 19 Sep 2023, at 10:42, Robin Jarry wrote:
>
>> Adrian Moreno, Sep 19, 2023 at 09:18:
Both OVSDB and appctl are literally JSON-RPC protocols. There is no
need to re-invent anything.
>>>
>>> Right. Isn't appctl simpler in this case?
On 19 Sep 2023, at 10:42, Robin Jarry wrote:
> Adrian Moreno, Sep 19, 2023 at 09:18:
>>> Both OVSDB and appctl are literally JSON-RPC protocols. There is no
>>> need to re-invent anything.
>>
>> Right. Isn't appctl simpler in this case? IIUC, it would still satisfy
>> the requirements: client
Adrian Moreno, Sep 19, 2023 at 09:18:
> > Both OVSDB and appctl are literally JSON-RPC protocols. There is no
> > need to re-invent anything.
>
> Right. Isn't appctl simpler in this case? IIUC, it would still satisfy
> the requirements: client decides update interval, flexible schema, etc
> with
On 9/18/23 20:24, Ilya Maximets wrote:
On 9/12/23 15:47, Eelco Chaudron wrote:
On 12 Sep 2023, at 15:19, Robin Jarry wrote:
Eelco Chaudron, Sep 12, 2023 at 09:17:
I feel like if we do need another way of getting (real time)
statistics out of OVS, we should use the same communication
On 9/12/23 15:47, Eelco Chaudron wrote:
>
>
> On 12 Sep 2023, at 15:19, Robin Jarry wrote:
>
>> Eelco Chaudron, Sep 12, 2023 at 09:17:
>>> I feel like if we do need another way of getting (real time)
>>> statistics out of OVS, we should use the same communication channel as
>>> the other
On 12 Sep 2023, at 15:19, Robin Jarry wrote:
> Eelco Chaudron, Sep 12, 2023 at 09:17:
>> I feel like if we do need another way of getting (real time)
>> statistics out of OVS, we should use the same communication channel as
>> the other ovs-xxx utilities are using. But rather than returning
>>
Eelco Chaudron, Sep 12, 2023 at 09:17:
> I feel like if we do need another way of getting (real time)
> statistics out of OVS, we should use the same communication channel as
> the other ovs-xxx utilities are using. But rather than returning
> text-based responses, we might be able to make it JSON
On 11 Sep 2023, at 12:41, Robin Jarry wrote:
> Hey Kevin,
>
> Kevin Traynor, Sep 07, 2023 at 15:37:
>> This came up in conversation with other maintainers as I mentioned I was
>> reviewing and the question raised was - Why add this ? if you want these
>> values exposed, wouldn't it be better to
Hey Kevin,
Kevin Traynor, Sep 07, 2023 at 15:37:
> This came up in conversation with other maintainers as I mentioned I was
> reviewing and the question raised was - Why add this ? if you want these
> values exposed, wouldn't it be better to to add to ovsdb ?
That's a good point. I had
On 31/08/2023 14:11, Robin Jarry wrote:
Since DPDK 23.03, it is possible to register a callback to report lcore
TSC cycles usage. Reuse the busy/idle cycles gathering in dpif-netdev
and expose them to the DPDK telemetry socket.
Hi Robin,
This came up in conversation with other maintainers
Robin Jarry, Aug 31, 2023 at 15:11:
> diff --git a/lib/dpif-netdev.c b/lib/dpif-netdev.c
> index 70b953ae6dd3..ebf43a0f62e4 100644
> --- a/lib/dpif-netdev.c
> +++ b/lib/dpif-netdev.c
> @@ -1427,6 +1427,41 @@ dpif_netdev_pmd_rebalance(struct unixctl_conn *conn,
> int argc,
> ds_destroy();
>
Since DPDK 23.03, it is possible to register a callback to report lcore
TSC cycles usage. Reuse the busy/idle cycles gathering in dpif-netdev
and expose them to the DPDK telemetry socket.
Upon dpdk_attach_thread, record the mapping between the DPDK lcore_id
and the dpif-netdev core_id. Reuse that
14 matches
Mail list logo
