https://bugs.linaro.org/show_bug.cgi?id=2494
--- Comment #7 from Bala Manoharan <bala.manoha...@linaro.org> --- Regards, Bala On 3 November 2016 at 19:36, <bugzilla-dae...@bugs.linaro.org> wrote: > https://bugs.linaro.org/show_bug.cgi?id=2494 > > --- Comment #6 from Maciej Czekaj <maciej.cze...@caviumnetworks.com> --- > (In reply to Bala Manoharan from comment #5) >> Application portability across multiple platforms can not be done without >> any modifications. However I do not have an issue is adding the minimal pool >> size as capability in the capability struct but in the point 2 of your >> initial suggestion states that pool size be given by the implementation >> based on the buffer requirements, since the pools are actually created by >> the implementation and the application gives buffer count and pool type >> can't this be internally handled by the implementation without the >> additional API. >> >> If we are on agreement here I can send a proposal to modify the capability >> struct. > > Yes, application specifies and creates a pool, so user needs to manually > account for increased pool consumption. > > Also, it is > nb_rx_queues*(rx_queue_depth+alloc_queue_depth) + nb_tx_queues*tx_queue_depth. > > In case of ThunderX the formula is > > (nb_rx_queues+nb_tx_queues)*1024 + ceil(nb_rx_queues/8)*8192 > > > Now the challenge is that the buffer consumption has to be known before > odp_pktio_open() since that call consumes the buffer pool... but there is no > call to be made on pktio before odp_pktio_open() because this is a factory > function for pktio objects. The best way would be to: > > 1.create pktio object without a pool > 2.config the number of queues > 3.ask about capabilities , including buffer needs > 4.create the pool with application specified size + internal consumption size > taken from capability > 5.start the interface > > Adding the pool in the first call to pktio complicates the whole thing, as it > is not possible to alter the pool size later and it is not possible to query > the pktio pool consumption before odp_pktio_open(). The pools are configured based on "num" packets of size "len" or smaller which it has to support so if a pool is configured to support 1024 packets of size 512K then it can only support 512 packets of size 1024K. The pools are linked at pktio level and not at queue level the maximum number of packets which it has to support across all queue in a pktio is "num". Since the pktio capability comes after the pktio_open(), so couldn't the application expose the maximum queue which it can support based on pool configured with pktio interface. > >> >> The real question I would like to understand is the expectation of this >> minimal buffer size lets say if the application requires 1024 >> packets/buffers in a pktio interface and the minimal buffer size is 512 then >> should be pool be configured with (1024 + 512) buffers and can the 512 >> buffer required by pktio interface be used for storing application packets? > > Yes, the buffers are shared btw internal queues and application, because they > are really used for internal queuing of packets in HW, e.g. the contain: > - packets waiting for reception in RX queue > - packets waiting for transmission in TX queue > - empty packets allocated for future reception > > If the driver is under heavy load, all those queues may be filled up and lead > to buffer starvation that is difficult to recover from and it certainly limits > the performance since lack of buffers leads to dropping traffic. Packets being dropped coz of buffer starvation is expected and acceptable under heavy load and usually this is handled using Random Early Discard when the buffer in the pool reaches a threshold limit. > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are on the CC list for the bug.
