On 6 April 2015 at 16:34, Bill Fischofer <[email protected]> wrote: > Isn't that just another term in the PMR? If I have a flow with four > different sized packets that I want to put in different pools then I simply > have a PMR to identify the flow as input to other PMRs that then segregate > by pkt_len into four final CoSes which map the flow to the same queue but > different pools.
I have the same opinion as Bill and I believe this approach gives freedom to application to configure which packet_len should go into which pool. Regards, Bala > > On Mon, Apr 6, 2015 at 5:28 AM, Taras Kondratiuk > <[email protected]> wrote: >> >> On 04/03/2015 07:53 PM, Bala Manoharan wrote: >>> >>> On 3 April 2015 at 22:00, Taras Kondratiuk <[email protected]> >>> wrote: >>>> >>>> On 03/30/2015 03:34 PM, Zhujianhua wrote: >>>>> >>>>> >>>>> @ Jerin Jacob: >>>>> What will happen if odp_cos_set_pool(odp_cos_t cos_id, >>>>> odp_buffer_pool_t >>>>> pool_id) was called twice? >>>>> Will the new pool_id replace the old one or the CoS have two pools? >>>>> >>>>> @Taras: >>>>> Assume: set several pools per pktio interface. >>>>> What will happen if two data plane applications share one physical >>>>> Ethernet port to receive packets? >>>>> Since the pool is per pktio interface, will these two applications >>>>> share >>>>> the same buffer pool? >>>>> If there is memory leak in one application, the other application will >>>>> be >>>>> disturbed. >>>>> Correct me if my understanding were wrong. >>>> >>>> >>>> >>>> That's a nice question. I'm afraid this use-case was not considered >>>> before. >>>> Do you want to split traffic between two applications via classifier? >>>> >>>>> >>>>> Maybe to let each CoS have more than one pool and limit the max number >>>>> of >>>>> Pool to for example 4 (Let the application designer decide how many >>>>> pools >>>>> are needed for each CoS) could be one option. >>> >>> >>> Hi, >>> >>> If we are attaching multiple pools per CoS what will be the >>> distribution algorithm for packets to each of the associated pools? >>> will it be a simple round-robin in that case wouldn't it be better to >>> attach a single pool of bigger size to the specific CoS? >> >> >> Packets will be distributed deterministically according to size. >> >> In fact distributing packets to different pools by their sizes is >> orthogonal to the rest of classification which is done by analyzing >> packet (header) content. IMO it was a mistake to combine them. They >> normally have different purposes. Classification by size is used to get >> efficient memory usage and decrease packet segmentation. While content >> classification is used to separate different 'types' of traffic. >> >> In KS2 platform these are two separate steps: >> 1. Packet is classified by a header content and directed to a Flow >> (ODP CoS analog). >> 2. Flow has a destination queue and up to 4 pools assigned. Exact pool >> is chosen based on a packet size. >> >> Actually, the initial use-case in this thread clearly demonstrates >> orthogonality of packet content and size classification: number of CoS'es >> explodes as <content_classes>*<size_classes>. >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> https://lists.linaro.org/mailman/listinfo/lng-odp > > _______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
