lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 5 Sep 2008 11:17:07 +0200
From:	"Johann Baudy" <>
To:	"Evgeniy Polyakov" <>
Subject: Fwd: Packet mmap: TX RING and zero copy

Hi Evgeniy,

> vmsplice() can be slow, try to inject header via usual send() call, or
> better do not use it at all for testing.
vmsplice() is short in comparison to splice()  ~ 200us !
This was just to show you that even this vmpslice duration of 80us
that is needed for each packet is too long to send only 1 packet.
I really need a mechanism that allow sending of ~ 40 packets of 7200K
in one system call to keep some cpu ressources to do other things.
(Not spending time in kernel layers :))

> Amount of gettimofday() and friends is excessive, but it can be a trace
> tool itself.
I've only observed a small performance between with and without
gettimeofday().(< 1MB/s). I've used it to do a light FTRACE and to get
duration of vmsplice.

> kill_fasync() also took too much time (top CPU user
> is at bottom I suppose?), do you use SIGIO? Also vma traveling and page
> checking is not what will be done in network code and your project, so
> it also adds an overhead.

Between kill_fasync() sys_gettimeofday() , I thought that we returned
to user space.
No SIGIO. But FYI, I use PREEMPT_RT patch.

>Please try without vmsplice() at all, usual
> splice()/sendfile() _has_ to saturate the link, otherwise we have a
> serious problem.

I've already tried sendfile only with standard TCP/UDP socket. I've
not saturated the link.
Around same bitrate.

> Not to distract you from the project, but you still can do the same with
> existing methods and smaller amount of work. But I should be last saying
> that creating tricky hacks to implement the idea should be abandoned in
> favour of the standards (even slow) methods :)
I understand your point that common solution are always better than
multiple hacks.
But I think that I have the same motivation than packet mmap IO developers .
This feature was introduced to make the capture process of raw socket
efficient. I just want to reach the same goal for transmission using
same mechanism.
We use those features only if we need performance at the driver level.


Johann Baudy

Johann Baudy
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists