[Question] virtio_user for kernel networking?

[krsna1729]

@trozet Curious if virtio_user was evaluated to provide kernel path, any comparisons with VPort, etc., you could point to. One advantage looks like in-tree vhost ko? I have not used either one.

https://doc.dpdk.org/guides/howto/virtio_user_as_exceptional_path.html

[kot-begemot-uk]

On 04/12/2019 18:44, Saikrishna Edupuganti wrote: @trozet <https://github.com/trozet> Curious if virtio_user was evaluated to provide kernel path, any comparisons with VPort, etc., you could point to. One advantage looks like in-tree vhost ko? I have not used either one. https://doc.dpdk.org/guides/howto/virtio_user_as_exceptional_path.html — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3?email_source=notifications&email_token=AC4TGWG4IGAL7PEPM7QPYMTQW73BZA5CNFSM4JVNBIL2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H6C4X5Q>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4TGWHKISOWILE6VRQROM3QW73BZANCNFSM4JVNBILQ>.

I started testing it and ran into a couple of issues versus the implementation I used. IMHO - the bess own module vs virtio are different use cases. You cannot use virtio if you are trying to talk to the host on which bess runs and you cannot use the bess own module if you want to talk to VMs.

…

-- Anton R. Ivanov https://www.kot-begemot.co.uk/

[krsna1729]

Can you expand on different use-cases part?

In the below example I imagined BESS to take place of testpmd and the tap interface that gets created (on virtio_user vdev creation in EAL init) will be moved into the netns of the container.

$ sudo dpdk/build/app/testpmd --no-pci -l 2-3 -n 4 \
  --vdev=virtio_user0,path=/dev/vhost-net,queue_size=1024 -- \
  -i --txd=1024 --rxd=1024

$ sudo ifconfig tap0 1.1.1.1/24 up

$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.048 ms
^C
--- 1.1.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.048/0.048/0.048/0.000 ms

# Host does not exist. Only to increase counters in testpmd port stats output.
$ ping 1.1.1.2
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
From 1.1.1.1 icmp_seq=1 Destination Host Unreachable
From 1.1.1.1 icmp_seq=2 Destination Host Unreachable
From 1.1.1.1 icmp_seq=3 Destination Host Unreachable

testpmd>show port stats all
  ######################## NIC statistics for port 0  ########################
  RX-packets: 92         RX-missed: 0          RX-bytes:  4312
  RX-errors: 0
  RX-nombuf:  0
  TX-packets: 45         TX-errors: 0          TX-bytes:  1962

  Throughput (since last show)
  Rx-pps:            1          Rx-bps:          400
  Tx-pps:            0          Tx-bps:            0
  ############################################################################

[kot-begemot-uk]

Bess does not set-up a tap with virtio, it only sets up a socket. It is designed specifically for VM use - something that takes only a vhost socket. A.

On 05/12/2019 04:03, Saikrishna Edupuganti wrote: Can you expand on different use-cases part? In the below example I imagined BESS to take place of testpmd and the tap interface that gets created (on virtio_user vdev creation in EAL init) will be moved into the netns of the container. $ sudo dpdk/build/app/testpmd --no-pci -l 2-3 -n 4 \ --vdev=virtio_user0,path=/dev/vhost-net,queue_size=1024 -- \ -i --txd=1024 --rxd=1024 $ sudo ifconfig tap0 1.1.1.1/24 up $ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.048 ms ^C --- 1.1.1.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss,time 0ms rtt min/avg/max/mdev = 0.048/0.048/0.048/0.000 ms # Host does not exist. Only to increase counters in testpmd port stats output. $ ping 1.1.1.2 PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data. From 1.1.1.1 icmp_seq=1 Destination Host Unreachable From 1.1.1.1 icmp_seq=2 Destination Host Unreachable From 1.1.1.1 icmp_seq=3 Destination Host Unreachable |testpmd>show port stats all ######################## NIC statistics for port 0 ######################## RX-packets: 92 RX-missed: 0 RX-bytes: 4312 RX-errors: 0 RX-nombuf: 0 TX-packets: 45 TX-errors: 0 TX-bytes: 1962 Throughput (since last show) Rx-pps: 1 Rx-bps: 400 Tx-pps: 0 Tx-bps: 0 ############################################################################ | — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3?email_source=notifications&email_token=AC4TGWGFTUMBCADAQVVYA6DQXB4QZA5CNFSM4JVNBIL2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF7M5MA#issuecomment-561958576>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4TGWGIO2GECIIAJ3GDD5TQXB4QZANCNFSM4JVNBILQ>.

-- Anton R. Ivanov https://www.kot-begemot.co.uk/

[trozet]

We currently use VPort to get a kernel interface added to BESS (called nimbess0), which is built into the bess ko. I think what you are suggesting here is instead of that, using the vhost exception path instead. Is that correct? It may be worth us looking into as we are facing some issues with how memory is being mapped in the vport driver on some of our servers. The other main advantage would be we perhaps wouldn't need the bess.ko? Which would be great to get rid of having to carry an out of tree kernel module.

As Anton mentioned there would probably be some changes required to get the kernel interface part done.

[krsna1729]

Yes @trozet . you would not need bess.ko since in the other case vhost.ko is in-kernel and like the guide mentions, its hardened and production tested.

[krsna1729]

Atleast to do a comparison analysis on robustness, deployment friendliness and definitely performance.

[trozet]

Thanks @krsna1729 let's leave this issue open and we can investigate it. I think it is worth moving to if we get the same functionality/performance and we can get rid of having to carry the bess kernel module.