Date: Thu, 14 Jul 2022 22:46:25 +0200 From: "Michael Yan Ka Chiu" <nyan@myuji.xyz> To: freebsd-hackers@freebsd.org Subject: Re: Dynamic VF mac address manipulation / Bhyve Message-ID: <01972a40-b8e3-494f-a3ca-a69c20f8fbee@www.fastmail.com> In-Reply-To: <YtB2/UbVGa28aFCq@FreeBSD.org> References: <YtB2/UbVGa28aFCq@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--058093b9ed0d4b1dbddbc06093576862
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
On Thu, Jul 14, 2022, at 10:05 PM, John wrote:
> Hi -
>=20
> I am slowly converting a Linux based qemu/kvm solution to FreeBSD
> Bhyve where VMs have mac addresses assigned to them.
> I have tried the following steps.
> # ifconfig ccv3 ether 02:22:33:44:55:66
AFAIK for SR-IOV, the PF driver is actually the one responsible to confi=
gure the VF, so setting the mac address via the VF interface cannot crea=
te a persistent mac address.
> devctl set driver -f pci0:65:0:20 ppt
>=20
> The VF device can now be passed into bhyve (65/0/20) but the new
> value 02:22:33:44:55:66 is lost and the prior value 02:00:00:00:00:00
> is seen by the vm - but we want 02:22:33:44:55:66. So the new mac is
> a property of the driver, not the VF.
>=20
>=20
> At this point I'm wondering if adding a -U (update) option to iovctl
> or a new standalone program to target an individual iface/vf pair
> for update might be the answer.
>=20
>=20
> Comments welcome.
>=20
> Thanks,
> John
I=E2=80=99m just thinking out loud here. I have work on similar tools an=
d have some thoughts on how to make VF more manageable. For example cur=
rently there=E2=80=99s no way to really tell the pf of the vf actually b=
elonging to, this is especially an issue with Sriov enabled nic as you c=
an=E2=80=99t keep track of the physical port number.
I think maybe a different ppt like driver (let=E2=80=99s just call it io=
v for now) can be useful. Maybe with this iov device, we can have the P=
F driver to register some hooks to reconfigure specific VF, show the top=
ology between PFs and VFs and even allow dynamic creation of VF if the P=
F driver can somehow support it?
Best,
Michael
--058093b9ed0d4b1dbddbc06093576862
Content-Type: text/html;charset=utf-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Thu, Jul 14,=
2022, at 10:05 PM, John wrote:<br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div>Hi -<br></div><div><br></div><div>I am slowly conve=
rting a Linux based qemu/kvm solution to FreeBSD<br></div><div>Bhyve whe=
re VMs have mac addresses assigned to them.<br></div></blockquote><div><=
br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>I have trie=
d the following steps.<br></div><div># ifconfig ccv3 ether 02:22:33:44:5=
5:66<br></div></blockquote><div><br></div><div>AFAIK for SR-IOV, the PF =
driver is actually the one responsible to configure the VF, so setting t=
he mac address via the VF interface cannot create a persistent mac addre=
ss.<br></div><blockquote type=3D"cite" id=3D"qt" style=3D""><div>devctl =
set driver -f pci0:65:0:20 ppt<br></div><div><br></div><div>The VF devic=
e can now be passed into bhyve (65/0/20) but the new<br></div><div>value=
02:22:33:44:55:66 is lost and the prior value 02:00:00:00:00:00<br></di=
v><div>is seen by the vm - but we want 02:22:33:44:55:66. So the new mac=
is<br></div><div>a property of the driver, not the VF.<br></div><div><b=
r></div><div><br></div><div>At this point I'm wondering if adding a -U (=
update) option to iovctl<br></div><div>or a new standalone program to ta=
rget an individual iface/vf pair<br></div><div>for update might be the a=
nswer.<br></div><div><br></div><div><br></div><div>Comments welcome.<br>=
</div><div><br></div><div>Thanks,<br></div><div>John<br></div></blockquo=
te><div>I=E2=80=99m just thinking out loud here. I have work on similar =
tools and have some thoughts on how to make VF more manageable. Fo=
r example currently there=E2=80=99s no way to really tell the pf of the =
vf actually belonging to, this is especially an issue with Sriov enabled=
nic as you can=E2=80=99t keep track of the physical port number.<br></d=
iv><div><br></div><div>I think maybe a different ppt like driver (let=E2=
=80=99s just call it iov for now) can be useful. Maybe with this i=
ov device, we can have the PF driver to register some hooks to reconfigu=
re specific VF, show the topology between PFs and VFs and even allow dyn=
amic creation of VF if the PF driver can somehow support it?<br></div><d=
iv><br>Best,</div><div>Michael<br></div><div><br></div></body></html>
--058093b9ed0d4b1dbddbc06093576862--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01972a40-b8e3-494f-a3ca-a69c20f8fbee>