02.04.2020 20:33, Thomas Monjalon пишет: > 02/04/2020 11:18, Ivan Dyukov: >> Hello Thomas, >> >> 01.04.2020 13:57, Thomas Monjalon пишет: >>> 30/03/2020 09:57, Ivan Dyukov: >>>> Some applications like pktgen use link speed to calculate >>>> transmission rate. It limits outcome traffic to hardcoded 10G. >>>> >>>> This patch adds speed devarg which allows to configure >>>> link speed of virtio device. >>> Is it really a good idea to fake such information? >>> Shouldn't it be managed differently in the application instead? >>> >>> >>> >> This is main stream of net devices. Device provides speed to >> application. Application calculates the packet rate. In case of virtio, >> speed is not limited by device. It could be specified by user. This >> patch just gives this posibility to user. > The other possibility is to return 0 meaning unknown speed. Yep. Right. Linux kernel virtio is implemented same way. They return -1, if user haven't specified other.
Legacy dpdk virtio code was always returned 10G speed before my patchset and I just keep this value to prevent breakages in applications like pktgen. > I don't see why this information should be saved in the driver space. The speed could be provided by qemu. Please see 5th patch in my patchset. It's not good idea to smash this code accross application and driver side. > The user can give this information to the application, > it would look more correct to me. > Note: the application is controlling the devargs passed to the driver, > so it can intercept such information. These changes are specific only for virtio driver. If application will treat speed argument, then it also should check that current driver is virtio and same code will be duplicated in every application. > > I understand it is easier to have the speed info at the same place > in all cases. But it avoids differentiating what is a reliable info, > and what is user-provided info. > > >
