[lng-odp] [API-NEXT PATCHv1 1/4] api: classification: add pmr create api

Packet match rule creation is modified to include source and destination class of service. Removes the ability to add any class of service directly with pktio. If a PMR needs to be applied at the pktio level the same should be applied to default class of service. Packet match rule destroy function

Re: [lng-odp] [API-NEXT PATCHv1 1/4] api: classification: add pmr create api

+ list On 22.01.16 17:46, Ivan Khoronzhuk wrote: It discussed several times when started to look at it and Bill proposed to add some cls environment. Finally, it's sent. After this change PMR is created while connection to CoSes, and it's eliminates ability to connect the same PMR to several Co

Re: [lng-odp] [API-NEXT PATCHv1 1/4] api: classification: add pmr create api

The question of contexts for stateful classification was discussed last July. We can discuss this further during tomorrow's public call to see if we want to pursue this for Monarch or if it should be considered a post-Monarch item.

Re: [lng-odp] [API-NEXT PATCHv1 1/4] api: classification: add pmr create api

Ping. Any feedback on the API definition and comments most welcome. Regards, Bala On 26 January 2016 at 06:37, Bill Fischofer wrote: > The question of contexts for stateful classification was discussed last > July. We can discuss this further during tomorrow's public call to see if > we want t

Re: [lng-odp] [API-NEXT PATCHv1 1/4] api: classification: add pmr create api

This is otherwise OK (and exactly the feature I was missing in the call yesterday), but I'm wondering the benefit of having both odp_pmr_set_t and odp_pmr_t types. API would be simpler with only one type. To me odp_pmr_t is a odp_pmr_set_t with only one matching rule in it, right? We could get

Re: [lng-odp] [API-NEXT PATCHv1 1/4] api: classification: add pmr create api

Okay. I will incorporate these changes in the next version. Regards, Bala On 28 January 2016 at 20:31, Savolainen, Petri (Nokia - FI/Espoo) wrote: > > This is otherwise OK (and exactly the feature I was missing in the call > yesterday), but I'm wondering the benefit of having both odp_pmr_set_