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

[rick]

For what it's worth: As a customer who is using the SS stack - we were 
more than pleased that we could achieve IPOIB (and RDS) failover without 
using the bonding driver. I believe this is direct result of the Virtual 
NIC approach SS is using.

Michael Krause wrote:

>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
>>    
>>
>
>
>
>_______________________________________________
>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
>
>  
>