Re: [dpdk-dev] Please stop using iopl() in DPDK

[Willy Tarreau]

Hi Stephen,

On Mon, Oct 28, 2019 at 09:42:53AM -0700, Stephen Hemminger wrote:
(...)
> > I'd see an API more or less like this :
> > 
> >   int ioport(int op, u16 port, long val, long *ret);
> > 
> > <op> would take values such as INB,INW,INL to fill *<ret>, OUTB,OUTW,OUL
> > to read from <val>, possibly ORB,ORW,ORL to read, or with <val>, write
> > back and return previous value to <ret>, ANDB/W/L, XORB/W/L to do the
> > same with and/xor, and maybe a TEST operation to just validate support
> > at start time and replace ioperm/iopl so that subsequent calls do not
> > need to check for errors. Applications could then replace :
> > 
> >     ioperm() with ioport(TEST,port,0,0)
> >     iopl() with ioport(TEST,0,0,0)
> >     outb() with ioport(OUTB,port,val,0)
> >     inb() with ({ char val;ioport(INB,port,0,&val);val;})
> > 
> > ... and so on.
> > 
> > And then ioperm/iopl can easily be dropped.
> > 
> > Maybe I'm overlooking something ?
> > Willy
> 
> DPDK does not want to system calls. It kills performance.
> With pure user mode access it can reach > 10 Million Packets/sec
> with a system call per packet that drops to 1 Million Packets/sec.

I know that it would cause this on the data path, but are you *really*
sure that in/out calls are performed there, because these are terribly
slow already ? I'd suspect that instead it's relying on read/write of
memory-mapped registers and descriptors. I really suspect that I/Os
are only used for configuration purposes, which is why I proposed the
stuff above (otherwise I obviously agree that syscalls in the data
path are performance killers).

> Also, adding new system calls might help in the long term,
> but users are often kernels that are at least 5 years behind
> upstream.

Sure but that has never been really an issue, what matters is that
backwards compatibility is long enough to let old features smoothly
fade away. Some people make fun of me because I still care a bit
about kernel 2.4 and openssl 0.9.7 compatibility for haproxy, so
yes, I am careful about backwards compatibility and smooth upgrades ;-)

Willy