14/10/2021 04:21, Xia, Chenbo:

From: Thomas Monjalon <redacted>

quoted

13/10/2021 19:56, Walker, Benjamin:

quoted

quoted

From: Thomas Monjalon <redacted>

In order to be perfectly clear, all the changes done around this option
enable_driver_sdk share the goal of tidying stuff in DPDK so that ABI

becomes

quoted

quoted

better manageable.
I think that nobody want to annoy the SPDK project.
I understand that the changes effectively add troubles, and I am sorry

about

quoted

quoted

that. If SPDK and other projects can manage with this change, good.
If there is a real blocker, we should discuss what are the options.

Thanks for your understanding

I completely understand the desire to make the ABI manageable. If I were in

your shoes, I'd be doing the same exact thing. What I don't currently
understand is the motivation behind this enable_driver_sdk option. My guess is
that it's one of two things.

quoted

\1 ABI manageability: You say that's the purpose above, and that was my

initial assumption. But wouldn't that necessarily mean, over time, no longer
considering the symbols that were defined by the header files as part of the
stable ABI?

Absolutely. The idea is that we don't guarantee ABI for the drivers.

quoted

If you still consider these symbols as part of the ABI in shared library

builds, then the enable_driver_sdk option does absolutely nothing to improve
the ABI situation, so why bother to have it at all? We can't have packaged
SPDK relying on symbols in a packaged DPDK that are not part of the official
ABI.

quoted

\2 Not supporting out-of-tree drivers: Another option is that you just don't

want people writing out of tree drivers.

We don't want complications due to support of out-of-tree drivers,
but we don't want to forbid them.

quoted

You can't just drop it outright because people already do it,
but you'd like to not support it for shared library builds at least.

I didn't think about it in these terms.
But saying we don't offer compatibility for shared library drivers
is not too far of "no support" indeed.

quoted

So I'd like to really understand which of these two motivated the

enable_driver_sdk option . Maybe it's not even one of the two above. If it is
#1, then I think maybe we can work with DPDK to define a very small set of
out-of-tree driver APIs/ABIs that need to continue to exist in the shared
libraries by default. I do think SPDK needs only a very small number. If it's
#2, then that's the entire SPDK use case and I'd ask you to reconsider the
direction.

Yes I think we need to agree on functions to keep as-is for compatibility.
Waiting for your input please.

So, do you mean currently DPDK doesn't guarantee ABI for drivers

Yes

but could have driver ABI in the future?

I don't think so, not general compatibility,
but we can think about a way to avoid breaking SPDK specifically,
which has less requirements.