On 25 June 2015 at 02:48, Ivan Khoronzhuk <ivan.khoronz...@linaro.org> wrote:
> > > On 24.06.15 19:57, Bala Manoharan wrote: > >> Hi Ivan, >> >> Pls see my comments inline. >> >> On 24 June 2015 at 09:13, Ivan Khoronzhuk <ivan.khoronz...@linaro.org >> <mailto:ivan.khoronz...@linaro.org>> wrote: >> >> Guys, sorry I didn't ask the following questions during the ODP >> meeting. >> I had an issue with my microphone and it seems the call was ended >> quickly. >> But I need to ask. Maybe it's better, it requires some illustration. >> >> For now, I need the answer on the following questions: >> >> - Are we going to use the API proposed by Taras? I mean when PMR is >> connected to CoSes while its creation. >> (https://lists.linaro.org/pipermail/lng-odp/2015-April/010975.html) >> >> - About PMR. Can we re-use the same PMR in several places? If no, then >> each PMR must have source and destination CoSes and can be created and >> connected to the CoSes in the same function. If yes, what will happen >> when PMR is deleted, it must be deleted in all places where it was >> used? >> What if I want to delete PMR in one place and leave it for others? >> I know that it can be up to user to allocate several same PMRs and >> delete them separately if he wants. But what the official behaviour >> about that? In case if PMR can be connected in several places, it >> requires >> me to emulate a lot of actions as in this case it has no 1:1 PMR >> mapping. >> And in case of platform I'm aware of I must postpone the physical >> allocation >> in the hardware, as it requires PMR to have CoSes while creating. >> >> >> This is something to be discussed since we want to have a similar >> behavior for both ingress and egress APIs >> the idea was go ahead with profiling model where the HWs which can >> effectively reuse the PMRs can do some optimization and defer from >> creating a single HW resource per PMR. But this point is up for >> discussion and I am not sure there was an agreement on the same. >> > > Yes. But I need to implement it now. > > > >> >> - About PMR order. Do the classification usage have some order >> requirements? >> For instance. Can the PMR that on level 4 (UDP port) be inserted >> before PMR >> that on level 3 (exact IP address): >> +----+ +------+ +----+ +------+ +----+ >> |CoS0| -> |PMR l4| -> |CoS1| -> |PMR l3| -> |CoS2| >> +----+ +------+ +----+ +------+ +----+ >> This use-case can be useful for example when we want to receive in >> CoS1 all UDP >> packets according to PMR l4 rule and exclude packets with IP that >> match PMR l3 >> rule. CoS2 in this case is some drop CoS. >> >> I know that it can be implemented in the following way: >> +------+ +----+ >> |PMR l3| -> |CoS2| >> +----+ / +------+ +----+ >> |CoS0| -> >> +----+ \ +------+ +----+ >> |PMR l4| -> |CoS1| >> +------+ +----+ >> In this case the packets with not needed IP will be stolen before >> matching >> the PMR l4 rule, because PMR l3 rule was connected first. This example >> requires some headache to implement on my board, if it's possible at >> all. >> But after that step I have another question: >> >> >> - Can we connect PMRs of different levels to the same src CoS? >> This question is also about ordering. The above example is OK, as we >> connected >> PMR l3 before PMR l4. But what if it's used like following: >> +------+ +----+ >> |PMR l4| -> |CoS1| >> +----+ / +------+ +----+ >> |CoS0| -> >> +----+ \ +------+ +----+ >> |PMR l3| -> |CoS2| >> +------+ +----+ >> In this case all packets of PMR l4 will go to CoS1 even they match >> PMR l3. Only >> when they didn't match PMR l4 they will go to match PMR l3. The >> issue is that >> it can't be implemented on platform I'm aware of. The hardware has >> separate >> tables for matching L3 and L4 levels, and L3 level must go before L4. >> >> - What action has to be done if user connected entries in the above >> examples >> order? It has to be reordered by implementation before allocating in >> hardware >> or implementation has to return an error. In case of reordering, I'm >> afraid it >> won't match the user needs. And this a question of portability. >> >> >> I am not sure if HWs will be able to support such a connection I believe >> most HWs can only process the packets in a layered manner i.e L2 will be >> processed before L3. Also in-case of classification the responsibility >> lies with the application to make sure that the rules are not programmed >> in this way. Since from the implementation it will not be possible to >> check for these error scenarios >> > > The user have to know what he can and what not. The hardware in one > case can support such kind of connect, in this case the application > works as expected. But when the application is moved to another h/w > that couldn't physically do like that, the application can behave > differently, and in best case it would exit with error instead of silently > doing wrong things. And it's a portability question. The application must > behave the same independently on platform, right? In this case the > implementation must at least generate an error. You might not say user try > like this, maybe it will work like you want, and after porting to another > platform - oh, try to implement it in another way... There is should be > some concrete requirements allowing to interpret what the user want in the > same way on different platforms. > For now it be better to check on implementation level and generate an > error. > I am not against implementation returning an error in this case. But the responsibility for correct configuration should be with the application. In any case if an application decides to migrate his code from one platform to another there are few configuration checks which has to be performed by the application like the maximum number of queues or the number of scheduling priorities supported on each platforms. Regards, Bala > > >> Regards, >> Bala >> >> >> - Do default CoS of pktio to be replaced in case when >> odp_pktio_default_cos_set() is called once again? >> >> _______________________________________________ >> lng-odp mailing list >> lng-odp@lists.linaro.org <mailto:lng-odp@lists.linaro.org> >> https://lists.linaro.org/mailman/listinfo/lng-odp >> >> >>
_______________________________________________ lng-odp mailing list lng-odp@lists.linaro.org https://lists.linaro.org/mailman/listinfo/lng-odp
