lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 12 Aug 2020 10:09:22 +0800
From:   Jason Wang <>
To:     Eli Cohen <>, "Michael S. Tsirkin" <>
Cc:     "" <>,
        "" <>,
        "" <>,
        "" <>,
        "" <>,
        Majd Dibbiny <>,
        Maor Dickman <>,
        Shahaf Shuler <>,
        Parav Pandit <>
Subject: Re: VDPA Debug/Statistics

On 2020/8/11 下午7:58, Eli Cohen wrote:
> On Tue, Aug 11, 2020 at 11:26:20AM +0000, Eli Cohen wrote:
>> Hi All
>> Currently, the only statistics we get for a VDPA instance comes from the virtio_net device instance. Since VDPA involves hardware acceleration, there can be quite a lot of information that can be fetched from the underlying device. Currently there is no generic method to fetch this information.
>> One way of doing this can be to create a the host, a net device for
>> each VDPA instance, and use it to get this information or do some
>> configuration. Ethtool can be used in such a case

The problems are:

- vDPA is not net specific
- vDPA should be transparent to host networking stack

>> I would like to hear what you think about this or maybe you have some other ideas to address this topic.
>> Thanks,
>> Eli
> Something I'm not sure I understand is how are vdpa instances created on mellanox cards? There's a devlink command for that, is that right?
> Can that be extended for stats?
> Currently any VF will be probed as VDPA device. We're adding devlink support but I am not sure if devlink is suitable for displaying statistics. We will discuss internally but I wanted to know why you guys think.

I agree with Michael, if it's possible, integrating stats with devlink 
should be the best. Having another interface with is just for stats 
looks not good.


> --

Powered by blists - more mailing lists