08/10/2024 20:49, Akhil Goyal: > Added rte_pmd_rvu_lf_bar_get() API to get BAR address > for application to configure hardware.
In my opinion, we should not return PCI BAR addresses to an application. We should make an effort to have all theses details managed in the driver. Giving this level of access to an app is a door we should probably not open. > +/** > + * Get BAR addresses for the RVU LF device. > + * > + * @param dev_id > + * device id of RVU LF device > + * @param bar_num > + * BAR number for which address is required > + * @param[out] va > + * Virtual address of the BAR. 0 if not mapped > + * @param[out] mask > + * BAR address mask, 0 if not mapped > + * > + * @return > + * Returns 0 on success, negative error code otherwise > + */ > +__rte_experimental > +int rte_pmd_rvu_lf_bar_get(uint8_t dev_id, uint8_t bar_num, size_t *va, > size_t *mask); The cover letter does not talk about this. The announced features are: " - Register mailbox callbacks for the other side to process mailboxes. - Register interrupt handler callbacks. - Process mailbox. - Set range of message IDs allowed for communication. " Having mailbox, callbacks and message IDs is perfectly fine. It should not be needed to get PCI BARs for this purpose. Maybe a level of abstraction is needed here. Also I feel mailbox messaging is something we could make generic in rte_device. As you may understand, I'm not a big fan of how the feature is implemented in this series.
