Thanks Mattias for the clarifications. 1 more question: This time it is about the inflight accounting for DSW. Here is my understanding: it seems to consider only the events which are *inside the scheduler* as in flight. I am trying to distinguish it from those which have been currently given to cores by the scheduler. The latter are not considered in flight since we dsw_port_return_credits as soon as dsw_event_dequeue_burst . So if these events which are in core currently do a FORWARD, there is a chance that those can fail. Ideally those FORWARDs should not fail -- which can happen with the current design as some NEWs can hog those credits freed up by the ones which have been dequeued by cores. Is this design of DSW intentional or an omission? If it is an omission I can work on a possible fix and run it by you.
Thanks -Venky On Fri, Dec 6, 2019 at 12:34 AM Mattias Rönnblom < mattias.ronnb...@ericsson.com> wrote: > On 2019-12-06 01:26, Venky Venkatesh wrote: > > I see that the provision in 18.11 eventdev DSW for maximum number of > queues > > is > > > > #define DSW_MAX_QUEUES (16) > > > > > > > > 1. If the number of queues needed is to be increased to 7 bits (i.e. > > 128) is there any issue (correctness, scale, performance) other than > > increased data structure size? > > No. > > > 2. I see that it is only used in the following structs: > > - struct dsw_evdev: struct dsw_queue queues[DSW_MAX_QUEUES]; > > sizeof(struct dsw_queue) ~ DSW_MAX_FLOWS. So the total increase > > contribution here is (128-16)*DSW_MAX_FLOWS from about 0.5MB to > 4MB > > - struct dsw_port: uint64_t queue_enqueued[DSW_MAX_QUEUES], > > queue_dequeued[DSW_MAX_QUEUES]; > > This increase is negligible (a few KB at most across all > dsw_ports) > > On x86_64, the size of the dsw_evdev-struct is increased by ~32 kB per > queue added. > > > 3. So is it enough if I changed the above define? (In other words I > hope > > there are no other hidden/implicit dependencies on the current value > 16 > > elsewhere in the code). Also I suppose the only way is to directly > change > > this in the code, rite? > > > > Yes, and yes. > > The original reason for having that define was that I thought 16 queues > would be enough for anyone. As so many in the past that has utter such > statements, I might well have been wrong. > > /M >
