On Fri, Apr 3, 2015 at 8:39 PM, Bill Fischofer <bill.fischo...@linaro.org> wrote: > The pool specified on odp_pktio_open() is simply the default pool to use if > a PMR doesn't provide a more specific match to a CoS. In the latter case > the pool associated with the CoS applies.
Should we update the doxygen documentation of odp_pktio_open to mention the pool is only used by the default CoS? > > On Fri, Apr 3, 2015 at 12:32 PM, Benoît Ganne <bga...@kalray.eu> wrote: >> >> Hi Bill, >> >> Thanks for the feedback. It was more or less what I was thinking about, >> but the fact that pktio_open() took a pool in parameter made me think it was >> per-iface. >> >> Thanks, >> Ben. >> >> >> Sent from Samsung Mobile. >> >> >> -------- Original message -------- >> From: Bill Fischofer >> Date:03/04/2015 18:14 (GMT+01:00) >> To: Benoît Ganne >> Cc: LNG ODP Mailman List >> Subject: Re: [lng-odp] ODP port to a new architecture >> >> Hi Benoît, >> >> What you describe seems quite doable with the current ODP API set, >> however, we're always looking to better refine them to best match the >> capabilities of the various platforms that support ODP--especially those >> that embody novel HW architectures--so I'd encourage you to participate in >> the mailing list and our regular weekly calls that Maxim has already >> mentioned. >> >> The ODP classifier APIs are intended to be very general and not tied to >> specific embodiments. PMRs can be associated with PktIO objects, but that's >> not a requirement. The intended flow is that packets are matched against >> PMRs to find the most-specific match and that process assigns a CoS to the >> arriving packet. A CoS, in turn, specifies both the pool that should be >> used to store the packet as well as the queue (or queue group) that it >> should be added to for scheduling. Queue groups are not part of ODP v1.0 >> but provide a means of distributing flow-related packets to individual >> related queues that form the queue group. We expect to be adding this >> capability to the APIs this year. >> >> So it sound like you'd want a pool per address space and use PMRs to sort >> arriving packets into a set of CoSes that map to the appropriate per-AS >> pool. >> >> Bill >> >> On Fri, Apr 3, 2015 at 10:20 AM, Benoît Ganne <bga...@kalray.eu> wrote: >>> >>> Hi Maxim, thanks for your quick answer! >>> >>>> Glad to see new people interesting ODP. There are many ways to >>>> participate: mailing list, regular public meeting on Tuesday or be a >>>> member of Linaro LNG team with it's benefits (drive next API >>>> development, use LNG infrastructure, set and prioritize tasks). >>> >>> >>> I will join Tuesday meetings. >>> Regarding Linaro membership, I couldn't find much information on the >>> Linaro website. Do you have pointers about what is required and what it >>> means? One of my concern is that our architecture is not ARM-based. ODP is >>> ISA-agnostic, but not sure about Linaro though. >>> >>>> If you go to http://www.opendataplane.org/ you can find different repos >>>> for odp. >>> >>> [...] >>>> >>>> So the best thing it to start with looking at linux-generic >>>> implementation, then branch it out to your local tree then start >>>> implement pktio and queue function. As reference how to do it best you >>>> can take a look at TI Keystone2 implementation or DPDK or Netmap. >>> >>> >>> Yes, this is what we started to do. And the only real issue we saw so far >>> is this pktio <--> pool association. >>> >>>> About address space I think you should be ok with implementation >>>> odp_shm_reserve() function which should take care about all your >>>> internal address spaces. >>> >>> >>> Right. The packet pool API itself fits nicely our needs. >>> >>>> Then you can create bunch of odp pools for each segment, then call >>>> odp_pktio_open() for each pool and then bind it to queue with >>>> odp_queue_create(). Does that work for you? >>>> Or might be in you configuration we should consider segmented pool >>>> support. I.e. if pool is represented with several memory chunks. >>> >>> >>> Not sure wether it could fix our issue. I will try to better explain, >>> here is what we have on the packet RX path: >>> +------------+ >>> | DISPATCHER | >>> iface0 ---> | X | ---> address space 0 >>> iface1 ---> | PMR | ---> address space 1 >>> iface2 ---> | CoS | ... >>> iface3 ---> | Scheduling | ---> address space N >>> +------------+ >>> >>> iface[0-3] are physical Ethernet interfaces. The DISPATCHER block receive >>> packets from various interfaces, and is responsible of classifying (ie >>> attributing a CoS) to incoming packets based on PMR. When the packet CoS is >>> determined, it will schedule it in CoS-aware and flow-aware manner. The >>> DISPATCHER can schedule packets to any address space. >>> The packets are not buffered by the DISPATCHER. They go through it, and >>> they will be buffered for processing in the target address space. >>> What does it means is that: >>> - packet pools are created in the various address spaces >>> - each configured CoS can be scheduled (in a flow-aware manner) to any >>> address spaces, or only in some of them (this is user-defined) >>> >>> My initial idea was to consider each iface as a pktio, create queues in >>> the various address spaces, and associate a CoS to a group of queues. When >>> the DISPATCHER determines the packet CoS, it can be schedule it in one of >>> the queue belonging to the CoS queue group, and the packet will end-up in >>> the address space of the selected queue. >>> But if I do that, I need to associate the packet pool to a queue rather >>> than a pktio. A packet would have the following path: ingress pktio --> PMR >>> --> CoS --> queue --> pool. >>> >>> Now, your proposal is to open a pktio in each address space. But it looks >>> to me that it means that packets from different CoS will use the same pool? >>> I would like to avoid that. >>> Moreover as PMR and CoS are defined per pktio, this would mean that each >>> address space could have its own PMR and CoS setup. This won't map well on >>> our HW. >>> >>> Thanks, >>> ben >>> >>> -- >>> Benoît GANNE >>> Field Application Engineer, Kalray >>> +33 (0)648 125 843 >>> _______________________________________________ >>> 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
