arguments in amd64 ddb via -msave-args

this diff takes advantage of -msave-args to allow ddb to print arguments in stack traces on amd64. -msave-args basically pushes the functions register arguments onto the stack, so the code looks before (in memory) the base pointer for them. the rest of the arguments get passed normally, ie, after

add -msave-args to gcc on amd64

i got sick of not having arguments in ddb stack traces on amd64. the lack of them is because the first 6 arguments are generally passed in registers, not on the stack. recovering the arguments seems to rely on dwarf, which is complicated, which is not something i think is right for ddb. solaris

use strtonum to parse the argument to -j in make

i cant remember why i was looking at this, but strtoll annoys me. ok? Index: main.c === RCS file: /cvs/src/usr.bin/make/main.c,v retrieving revision 1.119 diff -u -p -r1.119 main.c --- main.c 4 Jan 2016 10:59:23 -

Re: tcpdump: etherip fix

> On 8 Mar 2017, at 16:29, Jeremie Courreges-Anglas wrote: > > > https://tools.ietf.org/html/draft-housley-etherip-01 > > still proposes a 1 byte header, the first nibble is the version (2). > The published RFC specifies version 3 and a two bytes header. > >

Re: Preserve original pf flow classification

> On 7 Mar 2017, at 05:27, Mike Belopuhov wrote: > > There's no need to overwrite original flow ID assigned on > input so that it remains stable throughout the life of a > packet. The rationale is that output processing may split, > encapsulate or obfuscate a single stream

Re: priq: convert to mbuf lists

> On 2 Mar 2017, at 21:19, Mike Belopuhov <m...@belopuhov.com> wrote: > > On Thu, Mar 02, 2017 at 10:11 +0100, Martin Pieuchot wrote: >> On 02/03/17(Thu) 01:16, Mike Belopuhov wrote: >>> On 2 March 2017 at 00:56, David Gwynne <da...@gwynne.id.au> wrote: >&

Re: priq: introduce ifq_drop

On Wed, Mar 01, 2017 at 10:06:30PM +0100, Mike Belopuhov wrote: > I've realised that something like this would be nice for convenience, > but not crucial. I'd prefer not to pass the mbuf pointer, but there's > no decent way around it. the api published in ifq.h should list what can safely be

Re: priq: proposed change in the behavior

On Wed, Mar 01, 2017 at 10:03:42PM +0100, Mike Belopuhov wrote: > Priority queueing is the default policy in OpenBSD and it > distributes outgoing packets in 8 lists by priority (0-7) with > an aggregate queue depth set by the interface: pseudo interfaces > use IFQ_MAXLEN defined equal to 256,

use KERNEL_LOCK wrappers in arch/amd64

we have wrappers around these now. ok? Index: arch/amd64/amd64/intr.c === RCS file: /cvs/src/sys/arch/amd64/amd64/intr.c,v retrieving revision 1.48 diff -u -p -r1.48 intr.c --- arch/amd64/amd64/intr.c 22 Jun 2016 01:12:38 -

let the pool gc reclaim items from the per cpu caches

this diff lets the pool gc reclaim idle memory held by cpu caches. it does this by recording when the global depot of items was first added to. the gc checks that timestamp and if the depot hasnt been emptied again in the last 4 seconds, it moves a list of items from the depot back to the pools

dont need splvm in pool_gc_pages

jmatthew@ noticed that i still had this code in here, despite making it mandatory for pools to specify the IPL they operate at. ok? Index: subr_pool.c === RCS file: /cvs/src/sys/kern/subr_pool.c,v retrieving revision 1.205 diff -u

Re: percpu counters: replace KASSERT with CTASSERT

ok. > On 31 Jan 2017, at 10:41, Jeremie Courreges-Anglas wrote: > > > CTASSERT is more useful when the result of the test is known at compile > time. Build-tested on amd64 and armv7, ok? > > > Index: net/rtsock.c >

Re: global mbuf memory limit

On Tue, Jan 24, 2017 at 02:55:50AM +0100, Alexander Bluhm wrote: > On Wed, Dec 14, 2016 at 03:52:32PM +1000, David Gwynne wrote: > > > Wouldn't it make sense to use atomic operations to keep track of the > > > amount of memory that was allocated? > > > > the mtx m

Re: pool_debug

On Tue, Jan 24, 2017 at 04:46:01PM +1000, Martin Pieuchot wrote: > I'd like to force a yield() for every pool_get(9) using PR_WAITOK, just > like we do with malloc(9), in order to ensure that the NET_LOCK() is not > held across context switches. > > ok? ok > > Index: kern/subr_pool.c >

Re: add support for multiple transmit queues on interfaces

concurrently, therefore causing corruption of the ring state. this diff fixes that. On Mon, Jan 23, 2017 at 01:09:57PM +1000, David Gwynne wrote: > the short explanation is that this lets interfaces allocate multiple > ifq structures that can be mapped to their transmit rings. the >

add support for multiple transmit queues on interfaces

s->ifqop_free(ifq->ifq_idx, ifq->ifq_q); ml_purge(); } @@ -368,14 +380,25 @@ ifq_q_leave(struct ifqueue *ifq, void *q * priq implementation */ +unsigned int +priq_idx(unsigned int nqueues, const struct mbuf *m) +{ + unsigned int flow = 0; + + if (ISSET(m->m_

Re: use ifqueue packet statistics

On Mon, Jan 23, 2017 at 10:10:23AM +1000, Martin Pieuchot wrote: > On 22/01/17(Sun) 20:38, David Gwynne wrote: > > ifqueues count packets, therefore if_enqueue doesnt have to. > > > > this adds reading of the ifq counters into the if_data values so > >

use ifqueue packet statistics

ifqueues count packets, therefore if_enqueue doesnt have to. this adds reading of the ifq counters into the if_data values so userland still looks right. this is another step toward multiple tx queues. ok? Index: if.c === RCS

update if_opackets with if_obytes in if_enqueue

basically this unifies the meaning of and operations on the output packet andbyte counters. the byte counter currently means how many bytes were successfully queued in software for transmission. traditionally the if_opackets counter generally means how many packets were successfully queued on the

store and count packet stats on ifq structures

this has the ifq count the statistics kept for output packets that we currently count on an ifnet. unlike the ifnet stats, these are all maintained by the ifq as a matter of course except for the output errors counter. this means drivers wont have to account for outgoing packets like they do now,

HEAP data structure

enBSD$ +.\" +.\" Copyright (c) 2016 David Gwynne <d...@openbsd.org> +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\" copyright notice and th

Re: [patch] turn igmpstat into a set of percpu counters

> On 22 Dec 2016, at 20:51, Dimitris Papastamos wrote: > > On Sun, Dec 11, 2016 at 07:24:40PM +, Dimitris Papastamos wrote: >> Hi, >> >> I converted the igmp stats to use percpu counters. This work is >> basically the same as what dlg@ did for other parts of the stack. >> I

Re: global mbuf memory limit

> On 22 Nov 2016, at 21:20, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > >> Date: Tue, 22 Nov 2016 12:42:39 +1000 >> From: David Gwynne <da...@gwynne.id.au> >> >> right now pools that make up mbufs are each limited individually. >> >&

make ifconfig print vnetids in hex too

so things will look like this: vlan9: flags=8002 mtu 1500 lladdr 00:00:00:00:00:00 index 11 priority 0 llprio 3 vlan: 70 parent interface: vnetid: 70 (0x46) parent: none groups: vlan status: no carrier vxlan0:

stop letting interface up/down fail silently

at the moment if ifconfig foo0 up fails, nothing says so because the kernel doesnt propagate the return code from the IFFLAGS ioctl back to userland. it also reports a link state change before it actually tries to bring the interface up or down. the diff below shuffles the SIOCSIFFLAGS handling

ifconfig and tunnels using ipv6 link local addresses

the system is inconsistent wrt to tunnels and ipv6 link local addresses. there are three things to consider here: 1. configuring addresses on a tunnel 2. using addresses to encapsulate traffic 3. reading the addresses a tunnel uses the ioctls used for 1 and 3 use sockaddr_in6 to pass v6

improve gre handling in tcpdump

gre can do more things than tcpdump currently thinks it can. specifically, gre can be carried by ipv6, and it can encapsulate more than just ip and ppp packets. as such, this tells tcpdump to look at gre inside ipv6 packets. gre uses ethertypes to represent what protocol it contains, so instead

tcpdump ether proto lldp

this diff lets me easily ask tcpdump to show me lldp packets. without it i have to remember the protocol id, and i cant. ok? Index: nametoaddr.c === RCS file: /cvs/src/lib/libpcap/nametoaddr.c,v retrieving revision 1.19 diff -u -p

only free pool pages from the gc task

at the moment pages can be freed on a pool_put call and from the gc. it is a bit unfair that pool_get may end up doing the heavy lifting of allocating a pool page and pool_put wont have to do an equivalent free, but we should try and minimise the amount of work done in these hot paths. ok?

Re: per cpu counters for icmp

> On 18 Nov 2016, at 20:11, Jonathan Matthew wrote: > > This is much like the other per cpu counter conversions, except the counter > enum has gaps in it to match the arrays in struct icmpstat. ok by me > > Index: icmp_var.h >

Re: per cpu counters for rtstat

On Fri, Nov 18, 2016 at 03:30:48PM +1000, David Gwynne wrote: > i didnt even know these existed. > > turns out you can see them with netstat -sr jmatthew@ points out i didnt alloc the counters, and sparc64 says im bad at testing alignment. Index

per cpu counters for rtstat

i didnt even know these existed. turns out you can see them with netstat -sr Index: route.c === RCS file: /cvs/src/sys/net/route.c,v retrieving revision 1.338 diff -u -p -r1.338 route.c --- route.c 15 Nov 2016 10:09:28 -

use per cpu counters for udp statistics

its as close to the ipstat change as i can make it. ok? Index: net/pipex.c === RCS file: /cvs/src/sys/net/pipex.c,v retrieving revision 1.89 diff -u -p -r1.89 pipex.c --- net/pipex.c 15 Sep 2016 02:00:18 - 1.89 +++

malloc type for CPU counters

there isnt a nice bucket for per cpu counters to use. this makes a pretty obvious one. ok? Index: sys/malloc.h === RCS file: /cvs/src/sys/sys/malloc.h,v retrieving revision 1.113 diff -u -p -r1.113 malloc.h --- sys/malloc.h

use per cpu counters for ipstat

since counters are an array of uint64_t values, this uses an enum to list the indexes into such an array. we still export an ipstat struct to userland (which you can see with netstat -sp ip). the export cheats a bit because we know that the struct is a collection of u_longs, so we just iterate

let pool allocators advertise multiple page sizes

this turns the pa_pagesz member of a pool allocator into a bitfield. pool pages can be many different sizes, they arent restricted to just the size provided by the hardware. to support this without introducing a page allocator per page size, a single page allocator can be used to allocate many

Re: per-cpu caches for pools

> requests/s = 4093 > bandwidth in Mbit/s = 1428 > > Just ask if you want more details on the testsetup. > > BR > > Simon > > 2016-10-27 5:54 GMT+02:00, David Gwynne <da...@gwynne.id.au>: > > On Tue, Oct 25, 2016 at 10:35:45AM +1000, David Gwynne wrote:

avl trees

im sending this diff out so marc.info backs it up for me. avl trees are just binary search trees with a specific implementation of insert and delete so the trees remain balanced. rb trees are the same, so the diff factors the common functionality (which is everything except insert and remove)

Re: per-cpu caches for pools

On Tue, Oct 25, 2016 at 10:35:45AM +1000, David Gwynne wrote: > On Mon, Oct 24, 2016 at 04:24:13PM +1000, David Gwynne wrote: > > ive posted this before as part of a much bigger diff, but smaller > > is better. > > > > it basically lets things ask for per-cp

Re: network performance fun

> On 25 Oct 2016, at 16:31, Mike Belopuhov <m...@belopuhov.com> wrote: > > On 25 October 2016 at 08:25, Mike Belopuhov <m...@belopuhov.com> wrote: >> On 25 October 2016 at 02:34, David Gwynne <da...@gwynne.id.au> wrote: >>>> I see. I will double che

Re: per-cpu caches for pools

On Mon, Oct 24, 2016 at 04:24:13PM +1000, David Gwynne wrote: > ive posted this before as part of a much bigger diff, but smaller > is better. > > it basically lets things ask for per-cpu item caches to be enabled > on pools. the most obvious use case for this is the mbuf pools.

Re: network performance fun

On Tue, Oct 25, 2016 at 12:50:50AM +0200, Mike Belopuhov wrote: > On Tue, Oct 25, 2016 at 00:22 +0200, Hrvoje Popovski wrote: > > On 24.10.2016. 23:36, Mike Belopuhov wrote: > > > On Mon, Oct 24, 2016 at 19:04 +0200, Hrvoje Popovski wrote: > > >> Hi all, > > >> > > >> OpenBSD box acts as transit

Re: (re)name cpumem_realloc to cpumem_malloc_ncpus

thank you for looking at this. ive committed it with tweaks based on your suggestions. > On 24 Oct 2016, at 22:15, Alexander Bluhm <alexander.bl...@gmx.net> wrote: > > On Mon, Oct 24, 2016 at 02:48:03PM +1000, David Gwynne wrote: >> cos its not resizing the allocation

per-cpu caches for pools

ive posted this before as part of a much bigger diff, but smaller is better. it basically lets things ask for per-cpu item caches to be enabled on pools. the most obvious use case for this is the mbuf pools. the caches are modelled on whats described in the "Magazines and Vmem: Extending the

(re)name cpumem_realloc to cpumem_malloc_ncpus

cos its not resizing the allocation, its allocating them for new cpus. the same goes for counters_realloc being named counters_alloc_ncpus. this adds doco for them too. ok? Index: share/man/man9/counters_alloc.9 === RCS file:

Re: per cpu mbuf statistics

> On 22 Oct 2016, at 3:14 AM, Alexander Bluhm <alexander.bl...@gmx.net> wrote: > > On Fri, Oct 21, 2016 at 05:02:49PM +1000, David Gwynne wrote: >> this uses the recently added percpu counter api as the backend for >> the mbstats collection. >> >> ok? >

Re: mcl2k2 mbuf clusters

> On 14 Oct 2016, at 16:17, Ted Unangst <t...@tedunangst.com> wrote: > > David Gwynne wrote: >> this adds a pool backend for MCLGETI thats 2k+2 bytes in size, which >> can be used on some very common nics that have annoying constraints >> on their rx descriptor

mcl2k2 mbuf clusters

this adds a pool backend for MCLGETI thats 2k+2 bytes in size, which can be used on some very common nics that have annoying constraints on their rx descriptors. this in turn simplifies the code in those drivers and lets them always operate on ETHER_ALIGN boundaries. the pool is cheap, pages

Re: add in6 multicast support to vxlan(4) ; question on mbufs

On Tue, Oct 11, 2016 at 12:06:46AM +0200, Mike Belopuhov wrote: > On Fri, Oct 07, 2016 at 20:48 +1000, David Gwynne wrote: > > On Thu, Oct 06, 2016 at 12:13:20PM +0200, Mike Belopuhov wrote: > > > m_pullup will always get a new mbuf and on > > > strict alignment archi

M_PREPEND in vxlan encap on not strict-alignment archs

if the arch can cope with prepending on an unaligned address in vxlan, then let it do it. this means less work if we can get away with it. ok? Index: if_vxlan.c === RCS file: /cvs/src/sys/net/if_vxlan.c,v retrieving revision 1.49

Re: Strengthen Ethernet packet length checks on input

> On 9 Oct 2016, at 09:35, Mike Belopuhov wrote: > > After looking into alignment and other issues with encapsulated > Ethernet frames, turns out that not all our encapsulation drivers > do a good job of performing header length checks and can > potentially pass truncated

Re: syslogd milliseconds timestamp

> On 6 Oct 2016, at 07:07, Alexander Bluhm wrote: > > Hi, > > RFC 5424 says you should add 1 to 6 digits fractions of a second > to each syslog timestamp. As we do not measure the time in syslog(3), > it takes 100 microseconds on my laptop before syslogd(8) adds the >

optimise search for start of vmmap fill

uvm_map_fill_vmmap lets callers specify an address after which they are interested in entries. generally theyre interested in addresses after 0, but if you start further along the address space the lookup has to traverse the addresses looking for it. this can be optimised by borrowing the

pending timeouts in trpt

i think the change to move tcp timers to timeouts got this bit wrong. we do want to print the timer if it is pending, it doesnt make sense otherwise. ok? Index: trpt.c === RCS file: /cvs/src/usr.sbin/trpt/trpt.c,v retrieving

make snmpd explicitely include tree.h

at the moment its relying on a pf header. ok? Index: snmpd.h === RCS file: /cvs/src/usr.sbin/snmpd/snmpd.h,v retrieving revision 1.67 diff -u -p -r1.67 snmpd.h --- snmpd.h 16 Aug 2016 18:41:57 - 1.67 +++ snmpd.h 2

EVP_CipherFinal_ex for snmpd

this gets rid of a linker warning. the impression i get is that EVP_CipherFinal_ex explicitely does not do cleanup of the cipher context thing, while EVP_CipherFinal could if it wanted to. ok? Index: usm.c === RCS file:

move pf from RB macros to RBT code

the subject says it all. this is largely mechanical. ok? Index: if_pfsync.c === RCS file: /cvs/src/sys/net/if_pfsync.c,v retrieving revision 1.232 diff -u -p -r1.232 if_pfsync.c --- if_pfsync.c 21 Sep 2016 07:41:49 - 1.232

move nfs to RBT code

this switches nfs from using the RB macros to RBT functions. ok? Index: nfs_node.c === RCS file: /cvs/src/sys/nfs/nfs_node.c,v retrieving revision 1.64 diff -u -p -r1.64 nfs_node.c --- nfs_node.c 19 Mar 2016 12:04:16 -

Re: timeout_set_proc(9)

> On 26 Sep 2016, at 13:36, Ted Unangst <t...@tedunangst.com> wrote: > > David Gwynne wrote: >> +mtx_enter(_mutex); >> +while (!CIRCQ_EMPTY(_proc)) { >> +to = timeout_from_circq(CIRCQ_FIRST(_proc)); >> +

Re: timeout_set_proc(9)

On Sat, Sep 24, 2016 at 12:20:02PM +0200, Christiano F. Haesbaert wrote: > Am Samstag, 24. September 2016 schrieb David Gwynne : > > > On Fri, Sep 23, 2016 at 10:16:34PM -0700, Philip Guenther wrote: > > > On Fri, 23 Sep 2016, Christiano F. Haesbaert wrote: >

Re: clang and

> On 25 Sep 2016, at 01:32, Mark Kettenis wrote: > > clang warns by default about static functions that are unused. It > does this even for static inline functions, except when those > functions are defined in a header file. The RBT code in > has macros that define

Re: timeout_set_proc(9)

On Fri, Sep 23, 2016 at 10:16:34PM -0700, Philip Guenther wrote: > On Fri, 23 Sep 2016, Christiano F. Haesbaert wrote: > ... > > The diff as it is will deadlock against SCHED_LOCK. > > tsleep() calls sleep_setup(), which grabs SCHED_LOCK, > > Then sleep_setup_timeout() will grab timeout_mutex in

Re: _KERNEL in rwlock.h

> On 21 Sep 2016, at 17:15, Martin Pieuchot wrote: > > Do not export kernel prototypes to userland, structure definitions is > what we need... or do we need love? if you can #define love, let me know. > > ok? ok. > > Index: sys/rwlock.h >

Re: timeout_set_proc(9)

> On 19 Sep 2016, at 20:28, Mike Belopuhov <m...@belopuhov.com> wrote: > > On 19 September 2016 at 11:06, Martin Pieuchot <m...@openbsd.org> wrote: >> On 19/09/16(Mon) 13:47, David Gwynne wrote: >>> [...] >>> id rather not grow the timeout (or task fo

Re: timeout_set_proc(9)

On Fri, Sep 16, 2016 at 04:58:39PM +0200, Mark Kettenis wrote: > > Date: Thu, 15 Sep 2016 16:29:45 +0200 > > From: Martin Pieuchot > > > > After discussing with a few people about a new "timed task" API I came > > to the conclusion that mixing timeouts and tasks will result in:

move uvm_map_addr to RBT code

this tree uses all the red-black tree features, so its an interesting test of the RBT code. it uses the augment functionality in red black trees, which nothing else does, and poisons nodes. we dont have any other trees that do this. we also get some space back, of course. ok? Index:

Re: m_copym2 is unused, let's remove it

Yes, this is just a conservative first step to that. On 14 Sep 2016 12:00 p.m., "Todd C. Miller" wrote: > Looks OK. Do you intend to change m_copym0 to m_copym and remove > the deep copy code? > > - todd >

Re: m_copym2 is unused, let's remove it

> On 14 Sep 2016, at 11:08, David Gwynne <da...@gwynne.id.au> wrote: > > ok? > > Index: sys/arch/amd64/conf/GENERIC > === > RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v > retrieving revision 1.43

m_copym2 is unused, let's remove it

ok? Index: share/man/man9/mbuf.9 === RCS file: /cvs/src/share/man/man9/mbuf.9,v retrieving revision 1.103 diff -u -p -r1.103 mbuf.9 --- share/man/man9/mbuf.9 13 Sep 2016 19:56:55 - 1.103 +++ share/man/man9/mbuf.9

Re: axen(4) lladdr fix

> On 13 Sep 2016, at 19:37, Martin Pieuchot wrote: > > Doing... > > # ifconfig axen0 lladdr bla > > is currently broken because we don't update the MAC address in the > driver, which makes the chip drop all the packets unless in promisc > mode. > > Diff

subr_tree for netinet/ip_ipsp.[ch]

this gives us back 5k on amd64. ok? Index: ip_ipsp.c === RCS file: /cvs/src/sys/netinet/ip_ipsp.c,v retrieving revision 1.214 diff -u -p -r1.214 ip_ipsp.c --- ip_ipsp.c 23 May 2015 12:38:53 - 1.214 +++ ip_ipsp.c 6 Sep

use subr_tree in net80211

this moves 80211 over to using the function version of red-black trees. it gives us back the 2.5k of code that RB_GENERATE adds. ok? Index: ieee80211_ioctl.c === RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.c,v retrieving

fold pool_setipl into pool_init

now that all the pools set an ipl we dont have to support optional ipls. the ioff argument is and has been unused for many years, so this replaces it with an ipl argument. cos the ipl is set on init, we no longer need pool_setipl. most of semantic changes in diff has been done with coccinelle

Re: mount(8): strlen + malloc + snprintf == asprintf

t.net.au> > To: "Ali H. Fardan" <r...@firemail.cc>, Otto Moerbeek <o...@drijf.net> > Cc: David Gwynne <da...@gwynne.id.au>, tech <tech@openbsd.org>, > owner-t...@openbsd.org > > FWIW the reply seemed like a proper statement to me. > > T

manpage for new rbtree code

, OR TORT +.\" * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF +.\" * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. +.\" */ +.\" +.\" Copyright (c) 2016 David Gwynne <d...@openbsd.org> +.\" +.\" Permission

Re: mount(8): strlen + malloc + snprintf == asprintf

> On 5 Sep 2016, at 12:13, Ali H. Fardan wrote: > > You can't specify a buffer size in asprintf() therefore, it is not secure, > you can see that snprintf() does write to the `i` bytes to the buffer asprintf allocates the memory it needs to write to, unlike snprintf which

trade the rb tree in pools for subr_tree code

+#ifdef _KERNEL /* * Copyright (c) 2016 David Gwynne <d...@openbsd.org> Index: sys/pool.h === RCS file: /cvs/src/sys/sys/pool.h,v retrieving revision 1.59 diff -u -p -r1.59 pool.h --- sys/pool.h 21 Apr 2016 04:09:28 - 1.59 +++ sys

Re: bridge: drop gif(4) support

ok > On 31 Aug 2016, at 02:09, Martin Pieuchot wrote: > >

Re: Heads up to Xen users following -current

> On 30 Aug 2016, at 16:31, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > >> Date: Tue, 30 Aug 2016 07:48:09 +0200 >> From: Mike Belopuhov <m...@belopuhov.com> >> >> On Tue, Aug 30, 2016 at 09:58 +1000, David Gwynne wrote: >>> On Mon, Aug

Re: removing expired once rules in pf_purge_thread()

> On 17 Dec 2015, at 13:30, Richard Procter wrote: > > > Hi Sasha, > > On Fri, 18 Dec 2015, Alexandr Nedvedicky wrote: > >>> Right. I'll just note though that the patch as it stands allows >>> multiple winners [...] Whether that's a realistic issue, I don't

Re: Heads up to Xen users following -current

On Mon, Aug 29, 2016 at 08:30:37PM +0200, Alexander Bluhm wrote: > On Mon, Aug 29, 2016 at 07:10:48PM +0200, Mike Belopuhov wrote: > > Due to a recent change in -current the socket sending routine > > has started producing small data packets crossing memory page > > boundary. This is not

Re: turn rb tree code into functions in the kernel

On Fri, Aug 12, 2016 at 10:39:41AM -0400, Ted Unangst wrote: > David Gwynne wrote: > > i recently proposed replacing a hash with an rb tree somewhere in > > the network stack, but it was pointed out that rb trees are big. > > > > in hindsight i think the other person

splraise for pccbb(4)

i noticed this when trying to figure out what level a cardslot would interrupt at. now we have splraise this is a lot more straightforward. avoiding an splraise when we're not sure whats actually lower than IPL_BIO is not worth the effort. splraise to a lower level is fine. ok? Index: pccbb.c

Re: bigger mbuf clusters for sosend()

> On 22 Aug 2016, at 03:36, Hrvoje Popovski wrote: > > On 13.8.2016. 10:59, Claudio Jeker wrote: >> This diff refactors the uio to mbuf code to make use of bigger buffers (up >> to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in >> the same function. I see

Re: bigger mbuf clusters for sosend()

> On 18 Aug 2016, at 08:49, Alexander Bluhm wrote: > > On Wed, Aug 17, 2016 at 09:21:21PM +0200, Claudio Jeker wrote: >> On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote: >>> As I understand, we are hitting the global mbuf cluster limit. I >>> don't see

Re: per cpu memory in the kernel

On Wed, Aug 17, 2016 at 09:13:04PM +1000, David Gwynne wrote: > On Wed, Aug 17, 2016 at 08:27:19PM +1000, David Gwynne wrote: > > On Thu, Aug 11, 2016 at 02:43:16PM +1000, David Gwynne wrote: > > > ive been tinkering with per cpu memory in the kernel. > > > > mpi@

Re: bigger mbuf clusters for sosend()

On Wed, Aug 17, 2016 at 01:43:00PM +0200, Alexander Bluhm wrote: > On Sat, Aug 13, 2016 at 10:59:30AM +0200, Claudio Jeker wrote: > > to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in > > the same function. I see no point in not waiting for a cluster and instead > > chain

Re: per cpu memory in the kernel

On Wed, Aug 17, 2016 at 08:27:19PM +1000, David Gwynne wrote: > On Thu, Aug 11, 2016 at 02:43:16PM +1000, David Gwynne wrote: > > ive been tinkering with per cpu memory in the kernel. > > mpi@ wanted to see another example of moving something to per cpu counters > and challenge

Re: bigger mbuf clusters for sosend()

> On 17 Aug 2016, at 5:23 PM, Simon Mages wrote: > > Hi, > > this diff works for me. > > I tested TCP and Unix Domain Sockets. I did no performance tests though. > > I like this version better then the one i was working with, it really > is easier to read. cool.

Re: per cpu memory in the kernel

On Thu, Aug 11, 2016 at 02:43:16PM +1000, David Gwynne wrote: > ive been tinkering with per cpu memory in the kernel. mpi@ wanted to see another example of moving something to per cpu counters and challenged me to do tcpstat. the diff below does that, but with a couple of warts. firs

Re: finer grained art locking again

On Mon, Aug 15, 2016 at 10:08:16PM +1000, Jonathan Matthew wrote: > This removes ART's reliance on the kernel lock to serialise updates. > I sent out an earlier version of this prior to 6.0, but it didn't make it in. > Since then, we've decided to go with rwlocks in the packet processing path, >

Re: finer grained art locking again

> On 16 Aug 2016, at 08:28, Mark Kettenis wrote: > >> Date: Tue, 16 Aug 2016 08:21:42 +1000 >> From: Jonathan Matthew >> >> On Mon, Aug 15, 2016 at 02:47:29PM +0200, Mark Kettenis wrote: Date: Mon, 15 Aug 2016 22:08:16 +1000 From: Jonathan

replace the last uses of m_copym2 with m_dup_pkt

then i can delete it. ok? Index: net/pfkey.c === RCS file: /cvs/src/sys/net/pfkey.c,v retrieving revision 1.29 diff -u -p -r1.29 pfkey.c --- net/pfkey.c 22 Mar 2016 11:53:21 - 1.29 +++ net/pfkey.c 14 Aug 2016 09:44:20 -

Re: per cpu memory in the kernel

> On 13 Aug 2016, at 5:48 AM, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > >> From: Martin Pieuchot <m...@openbsd.org> >> Date: Fri, 12 Aug 2016 20:44:04 +0200 >> >> On 08/11/16 06:43, David Gwynne wrote: >>> ive been tinkering with per

Re: turn rb tree code into functions in the kernel

this updates the diff after the SLIST changes in uvm. On Thu, Aug 11, 2016 at 10:19:20AM +1000, David Gwynne wrote: > i recently proposed replacing a hash with an rb tree somewhere in > the network stack, but it was pointed out that rb trees are big. > > in hindsight i think the

Re: [PATCH] let the mbufs use more then 4gb of memory

Subject: Re: [PATCH] let the mbufs use more then 4gb of memory > To: David Gwynne <da...@gwynne.id.au> > > Hi, > > I think i found the problem with your diff regarding the bigger mbuf clusters. > > You choose a buffer size based on space and resid, but what happen

Re: per cpu memory in the kernel

On Thu, Aug 11, 2016 at 02:43:16PM +1000, David Gwynne wrote: > ive been tinkering with per cpu memory in the kernel. i think vi threw up a little bit on the diff i sent out, so this should work. it should also work on !MULTIPROCESSOR kernels now. some of that is fixes to the percpu.h b

Re: uvm kentry free list: use an SLIST instead of RB abuse

> On 8 Aug 2016, at 10:46 PM, Mark Kettenis <mark.kette...@xs4all.nl> wrote: > >> Date: Mon, 8 Aug 2016 21:56:23 +1000 >> From: David Gwynne <da...@gwynne.id.au> >> >> the current tracking of free static map entries is done as hand >> rolled

uvm kentry free list: use an SLIST instead of RB abuse

the current tracking of free static map entries is done as hand rolled list manipulations using pointers in an rb_entry. it's really confusing to read. since its simple list manipulations, this replaces the hand rolled code with an SLIST. ok? Index: uvm.h

Re: [PATCH] let the mbufs use more then 4gb of memory

On Wed, Jun 22, 2016 at 01:58:25PM +0200, Simon Mages wrote: > On a System where you use the maximum socketbuffer size of 256kbyte you > can run out of memory after less then 9k open sockets. > > My patch adds a new uvm_constraint for the mbufs with a bigger memory area. > I choose this area

<    2   3   4   5   6   7   8   9   10   11   >