On Wed, Feb 07, 2024 at 04:00:04PM +0530, Jerin Jacob wrote: > On Sat, Feb 3, 2024 at 12:59 PM Bruce Richardson > <bruce.richard...@intel.com> wrote: > > > > Update the device capability docs, to: > > > > * include more cross-references > > * split longer text into paragraphs, in most cases with each flag having > > a single-line summary at the start of the doc block > > * general comment rewording and clarification as appropriate > > > > Signed-off-by: Bruce Richardson <bruce.richard...@intel.com> > > --- > > V3: Updated following feedback from Mattias > > --- > > lib/eventdev/rte_eventdev.h | 130 +++++++++++++++++++++++++----------- > > 1 file changed, 92 insertions(+), 38 deletions(-) > > > */ > > #define RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED (1ULL << 2) > > /**< Event device operates in distributed scheduling mode. > > + * > > * In distributed scheduling mode, event scheduling happens in HW or > > - * rte_event_dequeue_burst() or the combination of these two. > > + * rte_event_dequeue_burst() / rte_event_enqueue_burst() or the > > combination of these two. > > * If the flag is not set then eventdev is centralized and thus needs a > > * dedicated service core that acts as a scheduling thread . > > Please remove space between thread and . in the existing code. >
ack > > * > > - * @see rte_event_dequeue_burst() > > + * @see rte_event_dev_service_id_get > > Could you add () around all the functions so that looks good across the > series? > Yes. I'll also standardize them on one-per-line. Some had two per line but put the third on a separate line because of code wrapping. Better to just have everything on its own line for consistency. > > > */ > > #define RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES (1ULL << 3) > > /**< Event device is capable of enqueuing events of any type to any queue. > > - * If this capability is not set, the queue only supports events of the > > - * *RTE_SCHED_TYPE_* type that it was created with. > > * > > - * @see RTE_SCHED_TYPE_* values > > + * If this capability is not set, each queue only supports events of the > > + * *RTE_SCHED_TYPE_* type that it was created with. > > + * The behaviour when events of other scheduling types are sent to the > > queue is > > + * currently undefined. > > I think, in header file, we can remove "currently" > Ack. > > p > > */ > > > > #define RTE_EVENT_DEV_CAP_PROFILE_LINK (1ULL << 12) > > -/**< Event device is capable of supporting multiple link profiles per > > event port > > - * i.e., the value of `rte_event_dev_info::max_profiles_per_port` is > > greater > > - * than one. > > +/**< Event device is capable of supporting multiple link profiles per > > event port. > > + * > > + * > > The above line can be removed. Ack. > > > + * When set, the value of `rte_event_dev_info::max_profiles_per_port` is > > greater > > + * than one, and multiple profiles may be configured and then switched at > > runtime. > > + * If not set, only a single profile may be configured, which may itself be > > + * runtime adjustable (if @ref RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK is set). > > + * > > + * @see rte_event_port_profile_links_set rte_event_port_profile_links_get > > + * @see rte_event_port_profile_switch > > + * @see RTE_EVENT_DEV_CAP_RUNTIME_PORT_LINK > > */ > >
