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 <[email protected]> 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 > [email protected] > https://lists.linaro.org/mailman/listinfo/lng-odp >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
