[openib-general] gen2 dev branch

[Hal Rosenstock]

Roland Dreier wrote:
> I'm very concerned about the lack of flexibility in the proposed API.
> For example, only allowing one manager to register per GSI class
> wouldn't work well for a subnet manager that wants to handle multicast
> queries in one thread and path record requests in another thread.

The GSI API can readily accomodate attribute as an additional parameter
if that is a requirement (and has been previously stated).

> Here's another way of putting it.  I think we should aim for:
> 
>     pid_t fork(void);
> 
> And right now I'm afraid we have:
> 
>     BOOL CreateProcess(
>       LPCTSTR lpApplicationName,
>       LPTSTR lpCommandLine,
>       LPSECURITY_ATTRIBUTES lpProcessAttributes,
>       LPSECURITY_ATTRIBUTES lpThreadAttributes,
>       BOOL bInheritHandles,
>       DWORD dwCreationFlags,
>       LPVOID lpEnvironment,
>       LPCTSTR lpCurrentDirectory,
>       LPSTARTUPINFO lpStartupInfo,
>       LPPROCESS_INFORMATION lpProcessInformation
>     );

I don't think that the above is a fair comparison.

It's seems to me it's more like the contrast of registering a 
MAD filter against the register GSI class call.

int ib_mad_handler_register(struct ib_mad_filter        *filter,
                            ib_mad_dispatch_func         function,
                            void                        *arg,
                            tTS_IB_MAD_FILTER_HANDLE    *handle);

where

struct ib_mad_filter {
 struct ib_device        *device;
 tTS_IB_PORT              port;
 __u32                    qpn;
 uint8_t                  mgmt_class;
 uint8_t                  r_method;
 uint16_t                 attribute_id;
 tTS_IB_MAD_DIRECTION     direction;
 tTS_IB_MAD_FILTER_MASK   mask;
 char                     name[TS_IB_MAD_FILTER_NAME_MAX];
};

int gsi_reg_class(u8 mgmt_class, 
    u8 mgmt_class_version, 
    char *hca_name,
    u8 port,
    enum ib_gsi_reg_flags reg_flags,
    ib_gsi_send_comp_handler send_comp_handler,
    ib_gsi_recv_handler recv_handler,
    void *context, 
    void **handle);

Some of the parameters to the register GSI class call could be collapsed 
under a single parameter as has been done in the MAD filter
if it is the width of the API that is the issue but I don't think that's
the core of the issue.

-- Hal