On 27 April 2016 at 18:31, Bala Manoharan <[email protected]> wrote:
> FYI > > > ---------- Forwarded message ---------- > From: Bala Manoharan <[email protected]> > Date: 27 April 2016 at 18:30 > Subject: Re: classification questions > To: Zoltan Kiss <[email protected]> > Cc: "Savolainen, Petri (Nokia - FI/Espoo)" <[email protected]> > > > > > Regards, > Bala > > On 25 April 2016 at 21:11, Zoltan Kiss <[email protected]> wrote: > >> Hi, >> >> This is what we talked about at the arch call, I summarized it up what >> I've found, so hopefully it'll be easier for you to comment: >> >> Socket, socket_mmap and dpdk pktio uses _odp_packet_cls_enq(), it can >> have 3 different returns: >> - pktio_select_cos(), odp_packet_alloc() or odp_packet_copydata_in() >> problem: returns 0, the caller then leaks the memory passed through *base, >> I think we should fix that. Plus, I think we should pass back some of these >> errors through odp_pktin_recv(). At least the alloc and copydata, not sure >> about pktio_select_cos(). What do you think? >> > > I thought this was fixed by your latest patch. Whenever the classification > returns an error then the packet is not freed and is returned to the > application and whenever it return an error then the packet needs to be > freed by the calling function. > Oops... Looks like I need to reword my previous comment.... I thought this was fixed by your latest patch. Whenever the classifier returns an error then the packet is not freed and is returned to the application and its application responsibility to free the packet and whenever the classifier returns 0 then the packet has been handled by the classifier and there is no further action required from the application. Regards, Bala > > - queue_enq() succeeds, and then it returns 0, the caller don't have to >> care. That's OK >> - queue_enq() fails, caller passes it back to pktin_poll(), which puts it >> on the pktio_entry->s.in_queue[...].queue. Is this what we want? Or should >> we rather drop the packet? What is the rationale for either decision? >> > > IMO, when queue_enq() fails the classifier should return an error to the > caller and the caller can free the packet. > > Regards, > Bala > > >> On the other hand, _odp_packet_classifier() (which is used by loopback, >> and I want to use it for ODP-DPDK) works a bit differently: >> - pktio_select_cos(), odp_packet_alloc() or odp_packet_copydata_in() >> problem AND queue_enq() failures: returns -1, the caller releases the >> buffer and update error stats. pktin_poll() never sees the packets failed >> in queue_enq(). This is the same question like above, we should have some >> consistency. Plus again, we might want to escalate the alloc and copydata >> failures. >> - queue_enq() succeeds, caller doesn't care anymore. >> > >> Regards, >> >> Zoltan >> > > >
_______________________________________________ lng-odp mailing list [email protected] https://lists.linaro.org/mailman/listinfo/lng-odp
