Hi Genis, The headroom per CoS API had been previously discussed in ODP and I will post a patch in API-NEXT to include this API for further discussion and approval.
Regards, Bala On 20 July 2015 at 22:53, Genis Riera <gri...@starflownetworks.com> wrote: > Hi Bala, > > Thank you again for your explanations. In the near future I will try to > use this API's to change my current solution. However, moving to the > previous point, will the work for defining headroom per CoS go on, or > doesn't it matter anymore? I continue thinking that it could be a good idea > to take into account for a future new API's, as you said before. > > Regards, > > Genís Riera Pérez. > > Genís Riera Pérez > Software Engineer at StarFlow Networks > Edifici K2M, S103 c/ Jordi Girona 31 > 08034 Barcelona > > E-mail: gri...@starflownetworks.com > > On Mon, Jul 20, 2015 at 7:03 PM, Bala Manoharan <bala.manoha...@linaro.org > > wrote: > >> >> Hi Genis, >> >> On 20 July 2015 at 22:18, Genis Riera <gri...@starflownetworks.com> >> wrote: >> >>> Hi Bala, >>> >>> I've been reflecting about this and I agree with you, seems to make more >>> sense defining a headroom size per CoS as a generic concept, however my use >>> case differs from it cause it's simpler. In my use case, so far, I only >>> need to define the same headroom size for all packet stored in a packet >>> pool memory. For this reason I proposed to define it at packet pool >>> creation level. However I have some doubts regarding to use this feature to >>> solve my use case. I wondered if using the following ODP API's: >>> >>> - uint32_t uarea_size // packet pool parameter from odp_pool_param_t >>> - void *odp_packet_user_area(odp_packet_t pkt); >>> - uint32_t odp_packet_user_area_size(odp_packet_t pkt); >>> >>> I would be able to store meta-data for each received packet to the >>> packet pool memory I initialize. When I create a packet pool memory and >>> define uarea_size, does it mean that each packet received on this pool have >>> a specific user memory area to store meta-data per-packet? If this is >>> correct, my use case already is solved, but regardles of it, I'm agree with >>> you to add a headroom per CoS. >>> >> >> Yes. uarea_size will be the user area associated with every packet >> allocated from this pool. >> This region could be used to store meta-data associated with each packet. >> eg the application might be interested to store a context per packet to >> hold some packet processing information and this context could be store in >> this uarea_size ( This uarea_size can hold a pointer if a bigger ctx needs >> to be stored) >> >> Headroom_size will denote the amount of data available before the start >> of the packet so that if the application wants to add additional header or >> increase the size of the L2/L3 protocol header then there is no need to >> copy the entire packet it can simply increase the headroom and modify the >> L2/L3 protocol header and it will be more performance efficient. >> >> Hope this helps >> >> Regards, >> Bala >> >>> >>> Best, >>> >>> Genís Riera Pérez. >>> >>> Genís Riera Pérez >>> Software Engineer at StarFlow Networks >>> Edifici K2M, S103 c/ Jordi Girona 31 >>> 08034 Barcelona >>> >>> E-mail: gri...@starflownetworks.com >>> >>> On Mon, Jul 20, 2015 at 3:00 PM, Bala Manoharan < >>> bala.manoha...@linaro.org> wrote: >>> >>>> Hi Genis, >>>> >>>> I would like you to validate whether the options of adding headroom per >>>> CoS work for you. >>>> >>>> IMO, adding headroom per CoS makes more sense since CoS defines a >>>> specific flow and the application might be interested to modify headroom >>>> per flow. Since with your current proposal the same is possible but that >>>> would mean you need to create different pools per different types of flows. >>>> >>>> Regards, >>>> Bala >>>> >>>> On 16 July 2015 at 00:20, Ivan Khoronzhuk <ivan.khoronz...@linaro.org> >>>> wrote: >>>> >>>>> Nicolas, >>>>> >>>>> On 15.07.15 20:49, Nicolas Morey Chaisemartin wrote: >>>>> >>>>>> You don t need to add the lng-odp part. The mailing list doed it on >>>>>> its >>>>>> own when it s not in the title already >>>>>> >>>>> >>>>> You cannot be sure and rely upon it. I'm often add someone else in CC >>>>> and in this case the letter doesn't pass through the list server. >>>>> It's good when the letter is seen by everyone with the same subject. >>>>> >>>>> >>>>> >>>>>> >>>>>> Envoyé depuis un mobile Samsung. >>>>>> >>>>>> >>>>>> -------- Message d'origine -------- >>>>>> De : Ivan Khoronzhuk >>>>>> Date :15/07/2015 18:34 (GMT+01:00) >>>>>> À : Bill Fischofer , Genis Riera >>>>>> Cc : ODP mailing list >>>>>> Objet : Re: [lng-odp] [PATCH] api: pool: add headroom init parameter >>>>>> to >>>>>> odp_pool_param_t >>>>>> >>>>>> >>>>>> >>>>>> On 15.07.15 19:20, Bill Fischofer wrote: >>>>>> > Any proposed API changes need to be tagged API-NEXT. Proper patch >>>>>> > procedure is the following: >>>>>> > >>>>>> > git clone http://git.linaro.org/lng/odp.git myodp >>>>>> > cd myodp >>>>>> > git checkout -b api-next origin/api-next >>>>>> > ...Make your changes and commits locally >>>>>> > git format-patch origin/api-next --subject-prefix="API-NEXT PATCH" >>>>>> >>>>>> --subject-prefix=lng-odp]\ [API-NEXT PATCH >>>>>> Correct me if I'm wrong >>>>>> >>>>>> > // Make sure your patches are checkpatch clean: >>>>>> > ./scripts/checkpatch *.patch >>>>>> > git send-email --to=lng-odp@lists.linaro.org >>>>>> > <mailto:lng-odp@lists.linaro.org> *.patch >>>>>> > >>>>>> >>>>>> You can simplify by adding hook to: >>>>>> .git/hooks/post-commit >>>>>> >>>>>> git show --format=email | ./scripts/checkpatch.pl --strict --mailback >>>>>> --show-types - >>>>>> >>>>>> Just to see issues when adding a commit. >>>>>> >>>>>> > >>>>>> > >>>>>> > On Wed, Jul 15, 2015 at 11:11 AM, Genis Riera >>>>>> > <gri...@starflownetworks.com <mailto:gri...@starflownetworks.com>> >>>>>> wrote: >>>>>> > >>>>>> > Ivan, >>>>>> > >>>>>> > If you have this compilation issues I can send again the patch >>>>>> > without this check, assuming always positive values. Is it >>>>>> right for >>>>>> > you? >>>>>> > >>>>>> > Genís Riera Pérez >>>>>> > Software Engineer at StarFlow Networks >>>>>> > Edifici K2M, S103 c/ Jordi Girona 31 >>>>>> > 08034 Barcelona >>>>>> > >>>>>> > E-mail: gri...@starflownetworks.com >>>>>> <mailto:gri...@starflownetworks.com> >>>>>> > >>>>>> > On Wed, Jul 15, 2015 at 6:04 PM, Ivan Khoronzhuk >>>>>> > <ivan.khoronz...@linaro.org <mailto:ivan.khoronz...@linaro.org >>>>>> >> >>>>>> wrote: >>>>>> > >>>>>> > Genis >>>>>> > >>>>>> > On 15.07.15 19:00, Genis Riera wrote: >>>>>> > >>>>>> > Hi, Ivan, >>>>>> > >>>>>> > Not, but I added this check just in case of error when >>>>>> > defines this >>>>>> > parameter (e.g., when misstyping). >>>>>> > >>>>>> > >>>>>> > Usually I have compilation error/warn when trying to >>>>>> compare >>>>>> > unsigned int on value < 0. >>>>>> > >>>>>> > >>>>>> > Best, >>>>>> > >>>>>> > Genís Riera Pérez >>>>>> > Software Engineer at StarFlow Networks >>>>>> > Edifici K2M, S103 c/ Jordi Girona 31 >>>>>> > 08034 Barcelona >>>>>> > >>>>>> > E-mail: gri...@starflownetworks.com >>>>>> > <mailto:gri...@starflownetworks.com> >>>>>> > <mailto:gri...@starflownetworks.com >>>>>> > <mailto:gri...@starflownetworks.com>> >>>>>> > >>>>>> > On Wed, Jul 15, 2015 at 5:54 PM, Ivan Khoronzhuk >>>>>> > <ivan.khoronz...@linaro.org >>>>>> > <mailto:ivan.khoronz...@linaro.org> >>>>>> > <mailto:ivan.khoronz...@linaro.org >>>>>> > <mailto:ivan.khoronz...@linaro.org>>> wrote: >>>>>> > >>>>>> > Hi, Genis >>>>>> > >>>>>> > On 15.07.15 18:47, Genis Riera wrote: >>>>>> > >>>>>> > A new headroom parameter is added to >>>>>> > odp_pool_param_t when the >>>>>> > pool is >>>>>> > type of ODP_POOL_PACKET, so that headroom size >>>>>> could be >>>>>> > configured at >>>>>> > pool initialization time (ODP application >>>>>> runtime). >>>>>> > >>>>>> > Signed-off-by: Genis Riera Perez >>>>>> > <gri...@starflownetworks.com >>>>>> > <mailto:gri...@starflownetworks.com> >>>>>> > <mailto:gri...@starflownetworks.com >>>>>> > <mailto:gri...@starflownetworks.com>> >>>>>> > <mailto:gri...@starflownetworks.com >>>>>> > <mailto:gri...@starflownetworks.com> >>>>>> > >>>>>> > <mailto:gri...@starflownetworks.com >>>>>> > <mailto:gri...@starflownetworks.com>>>> >>>>>> > >>>>>> > -- >>>>>> > include/odp/api/pool.h | 5 >>>>>> +++++ >>>>>> > platform/linux-generic/odp_pool.c | 10 >>>>>> +++++++++- >>>>>> > 2 files changed, 14 insertions(+), 1 >>>>>> deletion(-) >>>>>> > >>>>>> > diff --git a/include/odp/api/pool.h >>>>>> > b/include/odp/api/pool.h >>>>>> > index e5061ab..913f510 100644 >>>>>> > --- a/include/odp/api/pool.h >>>>>> > +++ b/include/odp/api/pool.h >>>>>> > @@ -82,6 +82,11 @@ typedef struct >>>>>> odp_pool_param_t { >>>>>> > /** User area size >>>>>> in >>>>>> > bytes. Specify >>>>>> > as 0 if no >>>>>> > user >>>>>> > area is needed. >>>>>> */ >>>>>> > uint32_t uarea_size; >>>>>> > + >>>>>> > + /** Packet headroom >>>>>> size in >>>>>> > bytes. The >>>>>> > maximum >>>>>> > and the >>>>>> > + default value is >>>>>> defined by >>>>>> > ODP_CONFIG_PACKET_HEADROOM. >>>>>> > + Use 0 for >>>>>> default. */ >>>>>> > + uint32_t headroom; >>>>>> > } pkt; >>>>>> > struct { >>>>>> > /** Number of >>>>>> timeouts in >>>>>> > the pool */ >>>>>> > diff --git a/platform/linux-generic/odp_pool.c >>>>>> > b/platform/linux-generic/odp_pool.c >>>>>> > index dcbdf07..9359e53 100644 >>>>>> > --- a/platform/linux-generic/odp_pool.c >>>>>> > +++ b/platform/linux-generic/odp_pool.c >>>>>> > @@ -201,7 +201,15 @@ odp_pool_t >>>>>> > odp_pool_create(const char *name, >>>>>> > case ODP_POOL_PACKET: >>>>>> > unseg = 0; /* Packets are >>>>>> always >>>>>> > segmented */ >>>>>> > - headroom = >>>>>> ODP_CONFIG_PACKET_HEADROOM; >>>>>> > + >>>>>> > + /* If headroom is not >>>>>> specified by >>>>>> > params, >>>>>> > + set it to the default */ >>>>>> > + if (params->pkt.headroom <= 0 >>>>>> || >>>>>> > + params->pkt.headroom > >>>>>> > ODP_CONFIG_PACKET_HEADROOM) >>>>>> > >>>>>> > >>>>>> > Can headroom be < 0? >>>>>> > >>>>>> > + headroom = >>>>>> > ODP_CONFIG_PACKET_HEADROOM; >>>>>> > + else >>>>>> > + headroom = >>>>>> > params->pkt.headroom; >>>>>> > + >>>>>> > tailroom = >>>>>> > ODP_CONFIG_PACKET_TAILROOM; >>>>>> > buf_num = params->pkt.num; >>>>>> > >>>>>> > >>>>>> > Genís Riera Pérez >>>>>> > Software Engineer at StarFlow Networks >>>>>> > Edifici K2M, S103 c/ Jordi Girona 31 >>>>>> > 08034 Barcelona >>>>>> > >>>>>> > E-mail: gri...@starflownetworks.com >>>>>> > <mailto:gri...@starflownetworks.com> >>>>>> > <mailto:gri...@starflownetworks.com >>>>>> > <mailto:gri...@starflownetworks.com>> >>>>>> > <mailto:gri...@starflownetworks.com >>>>>> > <mailto:gri...@starflownetworks.com> >>>>>> > <mailto:gri...@starflownetworks.com >>>>>> > <mailto:gri...@starflownetworks.com>>> >>>>>> > >>>>>> > >>>>>> > >>>>>> _______________________________________________ >>>>>> > lng-odp mailing list >>>>>> > lng-odp@lists.linaro.org <mailto: >>>>>> lng-odp@lists.linaro.org> >>>>>> > <mailto: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 <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 >>>>>> >>>>> _______________________________________________ >>>>> lng-odp mailing list >>>>> 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
