> On 31 Oct 2014, at 07:10, Alexander Bluhm wrote:
>
> Hi,
>
> Some performance measurements showed that socket splicing for TCP
> can be made faster. The main slowdown was that tcp_output() got
> called for every incomming packet. When copying through user-land
> this cannot happen as the sc
Don't need BUF_ and its NULL arg handling here.
Index: x509/x509_trs.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/x509/x509_trs.c,v
retrieving revision 1.16
diff -u -p -r1.16 x509_trs.c
--- x509/x509_trs.c 28 Sep 2014 10:52:59 -
Remove a few bits of junk, mostly support for dso loading of zlib
which i suspect is fully dead.
Index: c_rle.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/comp/c_rle.c,v
retrieving revision 1.7
diff -u -p -r1.7 c_rle.c
--- c_rle.c
It is my understanding of the code that ssh(1) no longer supports
DNSSEC. I say this because it calls getrrsetbyname(3) to check the
secure flag, which calls into the ASR machine. In asr.c, the `pass0'
function only parses two options, "tcp" and "ndots:", ignoring "edns0".
Indeed, the asr_run(3) ma
On Thu, Oct 30, 2014 at 22:10, Alexander Bluhm wrote:
> +
> + /* Avoid user land starvation. */
> + yield();
I think this is the responsibility of the taskq thread, not the
individual task.
Regarding the second pool diff, that looks very reasonable. Quite a
savings for a feature many mach
On Thu, Oct 30, 2014 at 10:10:20PM +0100, Alexander Bluhm wrote:
> I could try to put the splicing fields into a seperate struct
> that gets only allocated when needed.
This way I can shrink struct socket from 472 to 392 bytes on amd64.
When splicing gets active, another 88 bytes are allocated for
Since we cannot really guarantee that devices will be at the same place
on the USB tree and this stuff is unused, I don't see a reason to keep
it.
ok?
Index: usb_subr.c
===
RCS file: /cvs/src/sys/dev/usb/usb_subr.c,v
retrieving revis
Hi,
Some performance measurements showed that socket splicing for TCP
can be made faster. The main slowdown was that tcp_output() got
called for every incomming packet. When copying through user-land
this cannot happen as the scheduler gets involved.
So my idea is to do the socket splicing for
kern files, easy fixes.
Index: kern_sensors.c
===
RCS file: /cvs/src/sys/kern/kern_sensors.c,v
retrieving revision 1.29
diff -u -p -r1.29 kern_sensors.c
--- kern_sensors.c 14 Sep 2014 14:17:25 - 1.29
+++ kern_sensors.c
Ted Unangst wrote this message on Thu, Oct 30, 2014 at 12:09 -0400:
> On Mon, Oct 13, 2014 at 15:02, Arne Becker wrote:
>
> > OK, no more fiddling with O_NONBLOCK.
> > New diff below, tested with tcpbench and file transfers.
>
> I think this is good. Thanks, committed. We'll let it sit for a whil
On Mon, Oct 13, 2014 at 15:02, Arne Becker wrote:
> OK, no more fiddling with O_NONBLOCK.
> New diff below, tested with tcpbench and file transfers.
I think this is good. Thanks, committed. We'll let it sit for a while
and then see what if any changes need to take place on the buffer
side. Maybe
Hi,
This diff just swaps -2 with the actual constant to increase
readability of the ftp source code.
bye,
Jan
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.132
diff -u -p -r1.132 fetch.c
--- fetch
Thanks Landry
On Thu, Oct 30, 2014 at 09:40:14AM +0100, Landry Breuil wrote:
> On Thu, Oct 30, 2014 at 08:28:56AM +, Nicholas Marriott wrote:
> > No I think we are keeping the evutil.h file for now, the idea is just to
> > stop event.h including it.
>
> OKay, bulk started with just the eve
On Thu, Oct 30, 2014 at 08:28:56AM +, Nicholas Marriott wrote:
> No I think we are keeping the evutil.h file for now, the idea is just to
> stop event.h including it.
OKay, bulk started with just the event.h diff.
Landry
> On Thu, Oct 30, 2014 at 09:20:49AM +0100, Landry Breuil wrote:
> > On
No I think we are keeping the evutil.h file for now, the idea is just to
stop event.h including it.
On Thu, Oct 30, 2014 at 09:20:49AM +0100, Landry Breuil wrote:
> On Thu, Oct 30, 2014 at 08:14:35AM +, Nicholas Marriott wrote:
> > I'd like to see evutil.h go so I'm happy with this idea but
On Thu, Oct 30, 2014 at 08:14:35AM +, Nicholas Marriott wrote:
> I'd like to see evutil.h go so I'm happy with this idea but yes you will
> need to make sure it doesn't break ports, there are still quite a few
> ports that depend on the base libevent.
I'll run a bulk build with that. Apply dif
I'd like to see evutil.h go so I'm happy with this idea but yes you will
need to make sure it doesn't break ports, there are still quite a few
ports that depend on the base libevent.
On Thu, Oct 30, 2014 at 02:43:32AM +0100, Alexander Bluhm wrote:
> Hi,
>
> libevent has compatibilty wrappers in
17 matches
Mail list logo
