[openib-general] [PATCH 0/10] [RFC] Support for SilverStorm Virtual Ethernet I/O controller (VEx)

[Michael Krause]

Silverstorm is executing a usage model that the IBTA used to develop the IB 
protocols.   What is the problem with that?  If it works and integrates 
into the stack, then this seems like an appropriate bit of functionality to 
support.   The fact that one can use a standard ULP to communicate to a TCA 
as an alternative which is supported by the existing stack is a customer 
product decision at the end of the day.   If Silverstorm or any IHV can 
show value and that it works in the stack, then it seems appropriate to 
support.  Isn't that a fundamental principle of being an open source effort?


Mike


At 12:31 PM 10/3/2006, Fabian Tillier wrote:
>Hi Yaron,
>
>On 10/3/06, Yaron Haviv <yaronh at voltaire.com> wrote:
> >
> > I'm trying to figure out why this protocol makes sense
> > As far as I understand, IPoIB can provide a Virtual NIC functionality
> > just as well (maybe even better), with two restrictions:
> > 1. Lack of support for Jumbo Frames
> > 2. Doesn't support protocols other than IP (e.g. IPX, ..)
>
>Whether to use a router or virtual NIC approach for connectivity to
>Ethernet subnets is a design decision.  We could argue until we are
>blue in the face about which architecture is "better", but that's
>really not relevant.
>
> > I believe we should first see if such a driver is needed and if IPoIB
> > UD/RC cannot be leveraged for that, maybe the Ethernet emulation can
> > just be an extension to IPoIB RC, hitting 3 birds in one stone (same
> > infrastructure, jumbo frames for IPoIB, and Ethernet emulation for all
> > nodes not just Gateways)
>
>You're joking right?  Are you really arguing that SilverStorm should
>not develop a driver to support its existing devices?  This really
>isn't complicated:
>
>1). SilverStorm has a virtual NIC hardware device.
>2). SilverStorm is committed to support OpenFabrics.
>
>The above two statements lead to the following conclusion: SilverStorm
>needs a driver for its devices that works with the OpenFabrics stack.
>This is totally orthogonal to and independent of working on IPoIB RC
>or any IETF efforts to define something new.
>
>- Fab
>
>_______________________________________________
>openib-general mailing list
>openib-general at openib.org
>http://openib.org/mailman/listinfo/openib-general
>
>To unsubscribe, please visit 
>http://openib.org/mailman/listinfo/openib-general