> Well, you note I wrote qp != UD, where as that's really the qp_type, so
> the above was psuedo code at best. I was necessarily suggesting where
> in the qp data struct to store it, just that even though there isn't
> hardware that does this (yet), there's no reason hardware couldn't be
> designed to support both iWARP and RoCE and USNIC over the same Ethernet
> link layer, and merging the SoftRoCE and SoftiWARP drivers would make a
> proof of concept, and so we would *have* to store that information on a
> per QP basis.
>
> >
> Once Michael's patches are integrated, do apps need anything else
> > beyond the qp type as currently defined?
>
> If you had a device that supported iWARP and RoCE on the same physical
> link layer, then yes, the app would need a means of saying which
> transport to use in addition to the type of QP to establish.
Ah - got it now. And I agree, there should be some way to specify this at the QP level.
��.n��������+%������w��{.n�����{���fk��ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
