On Thu, Sep 18, 2026 at 03:06:49PM +0000, Bruce Richardson wrote:
> > + void (*interrupt_handler)(void *param);
> > + /* Optional vendor-specific handshake. If NULL, the built-in
> > + * scratchpad handshake is used. Used by hardware (e.g. AMD) whose
> > + * scratchpad layout differs from the built-in protocol.
> > + */
> > + int (*dev_handshake)(const struct rte_rawdev *dev);
> > + /* Optional vendor-specific peer-config read at device start. If NULL,
> > + * the built-in scratchpad reads are used.
> > + */
> > + int (*read_peer_config)(const struct rte_rawdev *dev);
> > };
>
> For these new op fields, do you foresee cases where other drivers might use
> the "default" functions as you have now? Might it be better to simplify
> things and always use driver-supplied ops, converting the existing
> functions into intel-specific ops, rather than making them fallback
> functions?
Thanks Bruce, that makes sense - I agree the uniform "always call the op"
style is cleaner than the NULL-fallback branches.
But the built-in handshake (ntb_handshake_work) and the peer-config read
in ntb_dev_start implement the scratchpad protocol considering
Intel-specific scratchpad layout
- vendor with similar intel scratchpad layout could reuse them . AMD is the
exception because
it has only 8 usable scratchpad registers per side and needs its own
packed layout. - Future vendors with similar AMD scratchpad layout would reuse
them.
If you think still it's essentially necessary will take up in next
iteration/v2:
Rather than hiding them as fallbacks, keep them as named,
reusable default ops and wire them into the Intel driver explicitly:
- export ntb_handshake_work and set .dev_handshake in intel_ntb_ops;
- factor the inline peer-config read in ntb_dev_start() into
ntb_spad_read_peer_config() and set .read_peer_config for Intel;
- set .interrupt_handler = ntb_dev_intr_handler for Intel;
- drop the "if (op != NULL) ... else ..." branches so the common code
always calls the op.
That removes the implicit fallbacks you are flagging while still letting any
future standard-scratchpad vendor opt into the generic implementations.
Thanks,
Raghavendra
