> 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: > > > > @@ -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
