The intent is that ODP APIs abstract the functionality that the application needs so that implementations have flexibility to migrate the low-level "how tos" into HW. This means that you DO NOT want the application to have responsibility for making housekeeping calls--these should be implicit in the implementation of ODP APIs. The goal is that SW is only involved for higher-level decision making that HW cannot do with sufficient flexibility. This means that by the time SW is called, everything is predigested and prestaged so that SW simply does its decision logic and returns the result back to HW, which takes it from there.
Not every implementation will be able to do this immediately, but if we keep that target model in mind it helps to guide the API design. On Fri, May 29, 2015 at 12:22 PM, Ola Liljedahl <ola.liljed...@linaro.org> wrote: > On 29 May 2015 at 18:03, Zoltan Kiss <zoltan.k...@linaro.org> wrote: > >> Hi, >> >> On 29/05/15 16:58, Jerin Jacob wrote: >> >>> I agree. Is it possbile to dedicate "core 0"/"any core" in ODP-DPDK >>> implementation >>> to do the house keeping job ? If we are planning for ODP-DPDK >>> implementation as just wrapper over DPDK API then there will not be any >>> value addition to use the ODP API. At least from my experience, We have >>> changed our SDK "a lot" to fit into ODP model. IMO that kind of effort >>> will >>> be required for useful ODP-DPDK port. >>> >> >> It would be good to have some input from other implementations as well: >> when do you release the sent packets in the Cavium implementation? >> > Most networking SoC's have HW buffer management. Buffers are automatically > freed after transmission. On reception, free buffers are automatically > allocated (potentially after classification so the HW knows which buffer > pool to use). HW buffer management actually saves a measurable amount of > cycles, on an old Freescale PowerQUICC device (with SW-managed RX/TX > rings), I estimated the overhead of SW buffer management (not thread-safe) > to be around 90 cycles which is a lot when the total per-packet cost was > around 600 cycles. > > > _______________________________________________ > 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
