On Tue, Nov 29, 2016 at 09:50:09AM -0700, Jason Gunthorpe wrote:
On Tue, Nov 29, 2016 at 04:44:37PM +0000, Hefty, Sean wrote:
> You are not making a subsystem. Don't overcomplicate things. A
> multi-part device device can just directly link.

The VNIC may be usable over multiple generations of HFIs, but I
don't know if that is the intent.

If Intel wants to build a HFI subystem within RDMA with multiple
drivers then sure, but they are not there yet, and we don't even know
what that could look like. So it is better to leave it simple for now.

Jason

Sorry for the delay, I was weighing in couple options.
We envisioned vnic as a pure software construct and hence should be independent (like ipoib). ie., both hfi_vnic and hfi1 should be independently loadable (like ipoib) despite hfi_vnic being dependent on hfi1 here for HW access.

There doesn't seem to be much value of hfi_vnic being a 'ib client', if it still has compilation and module dependency on hfi1 module.

The more I think of it, having vnic ops added to ib device structure (option (b)) makes it cleaner (no dependency). We can probably consider extending 'ib device' in hfi1 in order for hfi_vnic to get to the vnic ops. But (b) makes it simpler.

Though Jason's suggestion could be a temporary measure for this patch series, the above approach is what I would like to target here.

Niranjana

Reply via email to