netdev - Re: [ANNOUNCE] New driver vxge for Neterion's X3100 series 10 GbEPCIe adapter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 1 Apr 2009 10:53:27 +0800
From:	Yu Zhao <yu.zhao@...el.com>
To:	Ramkrishna Vepa <Ramkrishna.Vepa@...erion.com>
Cc:	"Duyck, Alexander H" <alexander.h.duyck@...el.com>,
	Leonid Grossman <Leonid.Grossman@...erion.com>,
	Netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [ANNOUNCE] New driver vxge for Neterion's X3100 series 10
	GbEPCIe adapter

On Wed, Apr 01, 2009 at 10:38:07AM +0800, Ramkrishna Vepa wrote:
> > For the most part I think the bit you would be interested in is the
> > "sysfs" patch, http://patchwork.kernel.org/patch/8066/, which is what
> I
> > had used in the original implementation to enable the VFs.  I am going
> > to push this to a module parameter similar to your max_config_dev.
> The
> > rest of the patches handle PF to VF communications and configuration
> > which it sounds like is handled via firmware for your adapter.
> [Ram]Currently, the messaging interface is not part of this driver
> submission and each function driver is independent of the other - there
> are no dependencies between the PF and the VF driver.
> 
> > Most of the changes you would probably need to make would be in
> > vxge_probe/vxge_remove.  All you would end up needing to do is call
> > pci_enable_sriov(pdev, max_config_dev - 1) on your physical function
> > devices and then you would end up getting exactly as many VFs as you
> > need.  The call should be safe since I am assuming your VFs don't
> > implement their own SR-IOV capability structures.  The cleanup would
> be
> > pretty strait forward as well since you would just need to call
> > pci_disable_sriov in remove.
> [Ram] When the device indicates that it is SRIOV capable in the pci
> config space, why not create the VF pci config spaces as part of the
> enumeration process? This way, there would be no change required for the
> network drivers. 

Yes, and that's what the PCI subsystem does. If the vxge VF is identical
to its PF, then vxge should be able to drive both PF and VF without any
modification.

Thanks,
Yu
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html