On Tue, Aug 24, 2021 at 07:16:41PM +0000, Ariel Elior wrote:

In our view the qed/qede/qedr/qedi/qedf are separate drivers, hence we used
function pointer structures for the communication between them. We use
hierarchies of structures of function pointers to group toghether those which
have common purposes (dcbx, ll2, Ethernet, rdma). Changing that to flat exported
functions for the RDMA protocol is no problem if it is preferred by you.

I wouldn't twist the driver into knots, but you definately should not
be using function pointers when there is only one implementation,
eliminating that would be a fine start and looks straightforward.

Many of the functions in the rdma ops do not look complicated to move,
yes, it moves around the layering a bit, but that is OK and probably
more maintainable in the end. eg modify_qp seems fairly disconnected
at the first couple layers of function calls.

In summary - we got the message and will work on it, but this is no small task
and may take some time, and will likely not result in total removal of any
mention whatsoever of rdma from the core module (but will reduce it
considerably).

I wouldn't go for complete removal, you just need to have a core
driver with an exported API that makes some sense for the device.

eg looking at a random op

qed_iwarp_set_engine_affin()

Is an "rdma" function but all it does is call
qed_llh_set_ppfid_affinity()

So export qed_llh and move the qed_iwarp to the rdma driver

etc

Jason