Page MenuHomeFreeBSD

bhyve: enable virtio-net mergeable rx buffers for tap(4)
ClosedPublic

Authored by vmaffione on Feb 2 2020, 10:00 PM.
Tags
None
Referenced Files
F105986905: D23472.id67977.diff
Mon, Dec 23, 12:27 PM
Unknown Object (File)
Sun, Dec 15, 8:46 PM
Unknown Object (File)
Sat, Dec 7, 12:52 PM
Unknown Object (File)
Tue, Dec 3, 1:05 AM
Unknown Object (File)
Oct 28 2024, 8:43 AM
Unknown Object (File)
Oct 17 2024, 11:38 PM
Unknown Object (File)
Oct 4 2024, 1:44 PM
Unknown Object (File)
Oct 4 2024, 6:41 AM

Details

Summary

This patch adds a new netbe_peek_recvlen() function to the net backend API. The new function allows the virtio-net receive code to know in advance how many virtio descriptors chains will be needed to receive the next packet. As a result, the implementation of the virtio-net mergeable rx buffers feature becomes efficient, so that we can enable it also with the tap(4) backend. For the tap(4) backend, a bounce buffer was introduced to implement the peeck_recvlen() callback, which means an additional packet copy on the receive datapath. In the future, it should be possible to remove the bounce buffer (and so the additional copy), by obtaining the length of the next packet from kevent data.

Test Plan

Tested VM-2-VM with tap(4) and vale(4).

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

usr.sbin/bhyve/net_backends.c
310 ↗(On Diff #67671)

I think we can replace this cycle with call buf_to_iov(priv->bbuf, priv->bbuflen, iov, iovcnt, 0)
https://svnweb.freebsd.org/base/head/usr.sbin/bhyve/iov.c?view=markup#l122

vmaffione added inline comments.
usr.sbin/bhyve/net_backends.c
310 ↗(On Diff #67671)

Good catch, thanks.

vmaffione marked an inline comment as done.

Has anybody tested this on e1000?

Fix: Keep into account virtio-net header when collecting rx buffers.

Ping. Any comments on this change?

This revision is now accepted and ready to land.Feb 18 2020, 11:45 AM

Sorry, I didn’t have time to test the patch. But as for the code, I have no questions.

In D23472#521553, @aleksandr.fedorov_itglobal.com wrote:

Sorry, I didn’t have time to test the patch. But as for the code, I have no questions.

It's fine with me if you want some time to test it.

In any case I tested 10 different combinations:

  • VM-2-VM + tap + virtio-net + mtu 1500
  • VM-2-VM + tap + virtio-net + mtu 9000
  • VM-2-VM + tap + e1000 + mtu 1500
  • VM-2-VM + tap + e1000 + mtu 9000
  • VM-2-VM + vale + virtio-net + mtu 1500
  • VM-2-VM + vale + virtio-net + mtu 9000
  • VM-2-VM + vale + e1000 + mtu 1500
  • VM-2-VM + vale + e1000 + mtu 9000
  • VM-2-host + tap + virtio-net + mtu 1500
  • VM-2-host + tap + virtio-net + mtu 9000

each one with ping (-D) and netperf. Everything looks good.

Ok, I'll just go ahead with the commit.

I tested this patch with various OS’s(windows, Ubuntu, centos) and didn’t find any issues. So, I think it’s ready to go.

In D23472#522420, @aleksandr.fedorov_itglobal.com wrote:

I tested this patch with various OS’s(windows, Ubuntu, centos) and didn’t find any issues. So, I think it’s ready to go.

Thanks!