Thread (56 messages) 56 messages, 8 authors, 2022-08-03

RE: [Patch v4 03/12] net: mana: Handle vport sharing between devices

From: Long Li <longli@microsoft.com>
Date: 2022-07-21 00:06:20
Also in: linux-hyperv, linux-rdma, lkml

Subject: Re: [Patch v4 03/12] net: mana: Handle vport sharing between
devices

On Tue, Jul 12, 2022 at 06:48:09PM +0000, Long Li wrote:
quoted
quoted
quoted
@@ -563,9 +581,19 @@ static int mana_cfg_vport(struct
mana_port_context *apc, u32 protection_dom_id,

 	apc->tx_shortform_allowed = resp.short_form_allowed;
 	apc->tx_vp_offset = resp.tx_vport_offset;
+
+	netdev_info(apc->ndev, "Configured vPort %llu PD %u DB %u\n",
+		    apc->port_handle, protection_dom_id, doorbell_pg_id);
Should this be netdev_dbg()?
The log buffer can be flooded if there are many vPorts per VF PCI
device and there are a lot of VFs.
The reason netdev_info () is used is that this message is important
for troubleshooting initial setup issues with Ethernet driver. We rely
on user to get this configured right to share the same hardware port
between Ethernet and RDMA driver. As far as I know, there is no easy
way for a driver to "take over" an exclusive hardware resource from
another driver.
This seems like a really strange statement.

Exactly how does all of this work?

Jason
"vport" is a hardware resource that can either be used by an Ethernet device, or an RDMA device. But it can't be used by both at the same time. The "vport" is associated with a protection domain and doorbell, it's programmed in the hardware. Outgoing traffic is enforced on this vport based on how it is programmed.

Hardware is not responsible for tracking which one is using this "vport", it's up to the software to make sure it's correctly configured for that device.

Long
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help