Date: Fri, 06 Apr 2018 16:16:23 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 215737] [bhyve] utilizing virtio-net truncates jumbo frames at 4084 bytes length Message-ID: <bug-215737-27103-1RYTdLEUEL@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-215737-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-215737-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215737 --- Comment #10 from P Kern <des.gaufres@gmail.com> --- (In reply to Harald Schmalzbauer from comment #9) Thanks for the code! Yes vmx(8) does support recv/xmit of 9k frames but in a case where the VM has 2 vmx(8) NICs, the 9k frames do not seem to be able to transit in one NIC and the out the other. So 9k frames only seem to "work" when the traffic terminates at the VM (...?). Just tested this scenario on the same VM with 2 Intel em(8) NICs: 9k frames seem to pass through the VM via em0<-->em1 (mtu 9k on both) without trouble. Under the same setup but with vmx0<-->vmx1, the 9k frames cannot seem to fl= ow thru: traffic will transit only after MTUs are set to 4096. I'd love to tweak the vmx3f driver but then the VM could not be used for anything we put into production (small group here. no other BSD kernel dive= rs). thx again --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-215737-27103-1RYTdLEUEL>