Date: Fri, 23 Jan 2015 12:53:20 +0200 From: Ciprian Barbu <ciprian.barbu@linaro.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: "freebsd-net@freebsd.org" <net@freebsd.org> Subject: Re: Netmap mempool Message-ID: <CADJJ_HaL7BZw=j35x5BhT0v8NRvi1d5cR1yUW=Q=imo6A2t8Lw@mail.gmail.com> In-Reply-To: <CA%2BhQ2%2BhUzPofZRC_zAD7r4gGxuW09EBAsA9CCBcfOOX3qTrG2Q@mail.gmail.com> References: <CADJJ_HZzevQy9891qnOgyiDz5xeGC%2BQFjhZBh-URmcmUs83nhA@mail.gmail.com> <CA%2BhQ2%2BhUzPofZRC_zAD7r4gGxuW09EBAsA9CCBcfOOX3qTrG2Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 22, 2015 at 9:03 PM, Luigi Rizzo <rizzo@iet.unipi.it> wrote: > On Thu, Jan 22, 2015 at 10:12 AM, Ciprian Barbu > <ciprian.barbu@linaro.org> wrote: >> Hello, >> >> I have some questions related to OpenDataPlane. I have implemented the >> I/O access using netmap for ODP but currently it's suffering from low >> performance due to packets being copied between the netmap slots and >> ODP buffers. >> >> I want to create ODP buffer pools on top of netmap memory but I'm >> concerned with three things: >> 1. how to keep a buffer for as long as needed without affecting the >> receive process; I guess I could use the NS_BUF_CHANGED flag in some >> way >> 2. the netmap memory may not be large enough to accommodate a complex >> ODP application >> 3. the ODP application may occasionally hold on to buffers for longer time >> > > there is a way to hold buffers without returning them to the ring > using the 'cur' pointer in the ring, see the netmap manpage how this > is implemented and how it works on the tx and rx path. > > However, before embarking in zero copy i'd like you to elaborate on what > you mean for "low performance" (how many pps you see) and what are > your expectations. In my experience low performance almost always comes > from insufficient batching or other application bottlenecks. I didn't do exact measurements, but there seemed to be a bottleneck somewhere, I will have another look, maybe I missed something. > > Zero copy tricks come with great complications to track who owns what, > sometimes with additional hidden overhead (e.g. if you change buffers the driver > has to reprogram the IOMMU) and often have a very limited effect > in real world applications. > > Sure the numbers do look good on benchmarks or academic papers, but there > people don't worry about robustness and code maintainability. > > cheers > luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADJJ_HaL7BZw=j35x5BhT0v8NRvi1d5cR1yUW=Q=imo6A2t8Lw>