rework ppp and pptp processing in tcpdump

i think i was looking at gre and pptp packets, and ended up going down a rabbit hole in ppp parsing. the original aim was probably to print the ppp payload in pptp packets, which tcpdump now does. eg: 23:52:00.197893 call 24 seq 7: gre-ppp-payload (gre encap) 23:52:00.198930 call 1 seq 7 ack

Re: on-line kernel debugging

> On 28 Jan 2018, at 04:07, bijan wrote: > > Thank you (for the quick response) and sorry if I was not as clear > as I should have been! what I meant and was hoping to find was > a source code debugger support, like gdb[1], where one can debug > a running kernel with

Re: tcpdump(8) USB support

> On 31 Jan 2018, at 12:39 am, Martin Pieuchot <m...@openbsd.org> wrote: > > On 30/01/18(Tue) 16:37, David Gwynne wrote: >>> [...] >>> bpfsdetach takes the reference to a bpf interface that bpfsattach >>> returns. the manpage likely isnt clear. the di

split MobileIP out of the gre(4) driver

v/null 1 Jan 1970 00:00:00 - +++ share/man/man4/mobileip.4 30 Jan 2018 07:07:32 - @@ -0,0 +1,139 @@ +.\"$OpenBSD$ +.\" +.\" Copyright (c) 2018 David Gwynne <d...@openbsd.org> +.\" +.\" Permission to use, copy, modify, and distribute this software for any +

Re: tcpdump(8) USB support

On Tue, Jan 30, 2018 at 04:32:11PM +1000, David Gwynne wrote: > On Fri, Jan 26, 2018 at 07:22:20AM +0100, Martin Pieuchot wrote: > > On 25/01/18(Thu) 14:55, Bryan Steele wrote: > > > On Thu, Jan 25, 2018 at 07:00:43PM +0100, Martin Pieuchot wrote: > > > > Diff belo

Re: tcpdump(8) USB support

On Fri, Jan 26, 2018 at 07:22:20AM +0100, Martin Pieuchot wrote: > On 25/01/18(Thu) 14:55, Bryan Steele wrote: > > On Thu, Jan 25, 2018 at 07:00:43PM +0100, Martin Pieuchot wrote: > > > Diff below adds support for dumping USB transfers via bpf(4), including > > > the tcpdump(8) bits. > > > > > >

rfc1241 ip encapsulation tunnels

$ */ + +/* + * Copyright (c) 2018 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 this permission notice appear in all copies. + * + * THE SO

Re: VMD: vioscsi - fix large iso support

> On 19 Jan 2018, at 4:32 pm, Carlos Cardenas wrote: > > Howdy. > > Attached is a patch to fix handling images > 4GB support in Linux. I > confused image size vs blocks to determine when to send UINT32_MAX > and trigger a READ_CAPACITY_16. > > Identified by mlarkin@ >

move carp interface pointers from struct ifnet to struct arpcom

both ethernet and carp interfaces use arpcom, so we can put the pointers there instead of wasting space in struct ifnet. ok? Index: net/if.c === RCS file: /cvs/src/sys/net/if.c,v retrieving revision 1.538 diff -u -p -r1.538 if.c ---

Re: merge vlan and carp input back into ether_input

On Thu, Jan 11, 2018 at 02:51:40PM +0100, Martin Pieuchot wrote: > On 11/01/18(Thu) 21:59, David Gwynne wrote: > > [...] > > when you say i break carp balancing, are you talking about the removal of > > the PACKET_TAG_CARP_BAL_IP tagging? PACKET_TAG_CARP_BAL_IP is only use

Re: constrain drm alloc_pages() to dma range

> On 12 Jan 2018, at 13:53, Jonathan Gray wrote: > > When trying to use alloc_page from ttm with radeon on an amd64 > machine with 8GB physmem the system would panic part way through > taking over the console along the lines of > > 'panic: Non dma-reachable buffer at paddr

have carp register detachhooks rather than get special handling in if.c

this makes carp less special by having it register detachhooks. right now if.c treats it better than it needs to. the diff shuffles establishment of the link status hook and the new detachhook to make carp_set_ifp fail if the hooks cannot be allocated. the following seems to work both before and

Re: bpf for subsystems, not just interfaces

> On 11 Jan 2018, at 23:54, Martin Pieuchot <m...@openbsd.org> wrote: > > On 11/01/18(Thu) 23:10, David Gwynne wrote: >> >> >>> On 11 Jan 2018, at 9:11 pm, Martin Pieuchot <m...@openbsd.org> wrote: >>> >>> On 11/01/18(Thu) 11:58, D

Re: bpf for subsystems, not just interfaces

> On 11 Jan 2018, at 9:11 pm, Martin Pieuchot <m...@openbsd.org> wrote: > > On 11/01/18(Thu) 11:58, David Gwynne wrote: >> im sending this out more as a backup than a serious diff. > > I love this. It's one of the steps to be able to use bpf(4) for USB. oh yeah.

Re: merge vlan and carp input back into ether_input

> On 11 Jan 2018, at 8:58 pm, Martin Pieuchot <m...@openbsd.org> wrote: > > On 11/01/18(Thu) 11:50, David Gwynne wrote: >> while we were working on making the various pseudo interfaces you >> stack on top of ethernet mpsafe, we split their input processing >>

Re: restrict carp use to ethernet interfaces

> On 11 Jan 2018, at 8:51 pm, Peter Hessler <phess...@theapt.org> wrote: > > On 2018 Jan 11 (Thu) at 20:41:19 +1000 (+1000), David Gwynne wrote: > :vlan and trunk are definitely ethernet interfaces. > : > > Is there anything in OpenBSD that isn't

Re: restrict carp use to ethernet interfaces

> On 11 Jan 2018, at 5:53 pm, Jonathan Gray <j...@jsg.id.au> wrote: > > On Thu, Jan 11, 2018 at 08:25:26AM +0100, Matthieu Herrb wrote: >> On Thu, Jan 11, 2018 at 10:29:17AM +1000, David Gwynne wrote: >>> carp interfaces output using ether_output, so i

Re: move gif_encap to simplify gif_start

On Thu, Jan 11, 2018 at 01:27:56PM +1000, David Gwynne wrote: > this avoids having to parse the gif packet before sending it to > bpf. instead, we stash the address family in the mbuf and add it > after bpf. > > however, a gif_encap error will not be propagated back to the sender.

cast __swapXX in _endian.h to help the compiler

this silences the warnings when building dhclient. according to guenther@, the c standard says ternary operators are subject to type promotion rules, ie, it ends up being at least an int. this adds explicit casts to the expected type, which makes printf happier when you tell it that it's a %hu

move gif_encap to simplify gif_start

this avoids having to parse the gif packet before sending it to bpf. instead, we stash the address family in the mbuf and add it after bpf. however, a gif_encap error will not be propagated back to the sender. i dont think this is a huge loss as the ip packet is usually encapsulated itself after

bpf for subsystems, not just interfaces

im sending this out more as a backup than a serious diff. this tweaks bpf so it can be used by subsystems, not just interfaces. this is done by making bpf store and use names (eg, "pf" and "em0") instead of just interfaces. interfaces get some special handling so you can't bpfwrite or enable

merge vlan and carp input back into ether_input

while we were working on making the various pseudo interfaces you stack on top of ethernet mpsafe, we split their input processing off so they could be attacked one by one. they're all mpsafe now, so this separation is not strictly necessary anymore. this moves carp and vlan input back into

restrict carp use to ethernet interfaces

carp interfaces output using ether_output, so it is reasonable to require that they only get configured on top of ethernet interfaces rather than just !IFT_CARP. there's some more simplification that can occur after this is done. ok? Index: ip_carp.c

get rid of struct carp_if by making if_carp itself an srpl

currently carp uses a struct carp_if to hold an srp list head, which is accessed by both if_carp in struct ifnet, and via the if input handlers list. this gets rid of some indirection by making if_carp itself the list head, and makes accessing the list consistent by only using if_carp to get to

Re: simplify valid carp interface check in carp_proto_input_if

so carp_output calls ether_output, which makes it pretty obvious that carp is for ethernet only. ie, this diff is safe. > On 10 Jan 2018, at 14:05, David Gwynne <da...@gwynne.id.au> wrote: > > this copies the "valid interface" check from carp6_proto_input_if

simplify valid carp interface check in carp_proto_input_if

this copies the "valid interface" check from carp6_proto_input_if to carp_proto_input_if. the current check looks to see if the current interface is carp, or if the current interface has any carps attached to it. the carp6_proto_input_if check just checks if the current interface is IFT_CARP or

shuffle protocol family input in ether_input()

the main change here is to defer chopping the ethernet header off the frame until just before the protocol input function is called. this means we don't have to reattach it for pppoe. ok? Index: if_ethersubr.c === RCS file:

make mpls_input take struct ifnet *ifp as an argument

i want this so it makes mpls_input have the same function signature as all the other protocol input functions we care about. it also helps mpls_input because it looks up the interface the mpls packet was received on, but it's always called by the interface that the packet was receieved on. on a

interface tx mitigation, with NET LOCK fixes

this is tx mitigation again, ie, defer calling an interfaces start routine until at least 4 packets are queued, or a task fires. the task firing is a problem for things like gif or vxlan that encap a packet in ip and send it through the ip stack again. the ip stack expects NET_RLOCK to be held.

use inline functions instead of __statement

my theory is that __statement (a gcc extension) was used to allow macros to evaluate their argument(s) once by assigning it to a local variable, and then returning a value. this is difficult with normal macros. these days you can use inline functions to get the same effect, but it is a more

Re: ASMedia ASM1061 SATA support for ahci(4)

> On 3 Jan 2018, at 08:25, Mark Kettenis wrote: > > This cip advertises itself as a PCI IDE controller, but actually > implements an AHCI interface. Adding it to the ahci_devices lists, > without any quirks makes ahci(4) work. It doesn't actually work with > our

Re: clock_gettime: add CLOCK_BOOTTIME clockid

> On 15 Dec 2017, at 10:47, Scott Cheloha wrote: > > Hi, > > Attached is a diff adding a new clockid, CLOCK_BOOTTIME, for use with > clock_gettime(2). The value of CLOCK_BOOTTIME is the time elapsed > since the system booted, i.e. the system uptime. The diff puts it

simplify sched_barrier with a wait condition on the stack

this started as just using struct cond to handle the sleep and wakeups for sched_barrier, but it got a bit bigger. the biggest semantic change is that it gets rid of the sbar taskq and uses systqmp instead. a whole thread (which is what is underneath a taskq) is a very big hammer for solving this

Re: Change bcopy to memcpy (i386 VIA PadLock driver)

> On 14 Dec 2017, at 07:23, Frederic Cambus wrote: > > Hi tech@, > > This diff changes bcopy to memcpy in the i386 version of the VIA PadLock > driver. It was done a while ago in the amd64 version of the driver. > > Comments? OK? ok > > Index: sys/arch/i386/i386/via.c >

disable hw vlan tagging support in ix(4)

im still looking at vlan performance problems, as discussed by mpi@ at http://www.grenadille.net/post/2017/02/13/What-happened-to-my-vlan. recently it occurred to me that we're making an implicit assumption that having the chip handle the injection of vlan tags has zero cost, and that all the

factor out common wait condition code

Jan 1970 00:00:00 - +++ share/man/man9/cond_init.9 12 Dec 2017 06:05:56 - @@ -0,0 +1,108 @@ +.\"$OpenBSD$ */ +.\" +.\" Copyright (c) 2017 David Gwynne <d...@openbsd.org> +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.

Re: Removal of PIM support in kernel

> On 12 Dec 2017, at 02:41, Dan Shechter wrote: > > I know I am about to be hammered here but... > > Without reading the sources, and being a Cisco admin, I am asking this > question: What PIM got to do with the kernel? PIM is just a > signaling/routing protocol, like

dhcrelay bpf bugs

there are two bugs in the bpf code in dhcrelay. they're obviously rare though. the worst one is when skipping a packet, dhcrelay uses the = operator instead of + when summing the bpf header and capture length. the second bug is also in calculating how much space a packet consumes to skip over

handle multiple interface addresses in dhcrelay

we were running out of space on a network here, but rather than make the network bigger, we added a separate ip address space to it. we use dhcrelay on these networks to provde addresses for the machines on this network. dhcpd relies on the gateway address inside a dhcp packet to figure out which

timeout_barrier(9)

this adds a timeout_barrier function, which works like all the other barriers we have (intr_barrier, ifq_barrier, etc). my use case for this is a network driver im working on, which uses a timeout to refill the rx ring if no mbufs are available in the system, but needs to wait for a timeout to

Re: add an iqdrops view to systat to show interface queue drops

> On 17 Nov 2017, at 05:39, Claudio Jeker <cje...@diehard.n-r-g.com> wrote: > > On Thu, Nov 16, 2017 at 03:21:20PM +0100, Alexander Bluhm wrote: >> On Wed, Nov 15, 2017 at 01:29:42PM +1000, David Gwynne wrote: >>> im adding numbers to input and output qdrops

Re: add an iqdrops view to systat to show interface queue drops

On Thu, Nov 16, 2017 at 07:22:48AM -0700, Theo de Raadt wrote: > > Now ifstat and iqdrops show almost the same information. Just two > > commns are different, eight culumns are redundant. I think one > > page would be better. Do we need DESC? It takes a lot of space > > that could be used for

Re: mbuf statistics, tracking of drops

On Thu, Nov 16, 2017 at 08:13:39PM +0100, Gregor Best wrote: > On Thu, Nov 16, 2017 at 11:13:04AM +1000, David Gwynne wrote: > > > > > On 16 Nov 2017, at 7:23 am, Gregor Best <g...@unobtanium.de> wrote: > > > > > > Hi, > > > > > >

Re: mbuf statistics, tracking of drops

> On 16 Nov 2017, at 7:23 am, Gregor Best <g...@unobtanium.de> wrote: > > Hi, > > On Mon, Nov 13, 2017 at 01:47:01PM +1000, David Gwynne wrote: >> [...] >> pools maintain count of how many times they failed to provide an >> allocation. you can w

add an iqdrops view to systat to show interface queue drops

im adding numbers to input and output qdrops in the kernel, so im aware that they exist now. however, i don't really see these values in userland. it seems netstat and systat think errors are more important. i tried adding qdrops to the ifstat view, but it got too cluttered. so i made a new view

if_rxr_livelocked

if a driver determines that an rx ring is generating too much load, it can notify the rxr ring accounting stuff of this. the effect is that it may lower the current watermark on the ring, therefore restricting the number of packets that will enter the system in the future. this also adds

Re: multiple interface input queues

> On 14 Nov 2017, at 23:17, Martin Pieuchot <m...@openbsd.org> wrote: > > On 14/11/17(Tue) 14:42, David Gwynne wrote: >> this replaces the single mbuf_queue and task in struct ifnet with >> a new ifiqueue structure modelled on ifqueues. > > The name is con

Re: multiple interface input queues

On Tue, Nov 14, 2017 at 02:42:30PM +1000, David Gwynne wrote: > this replaces the single mbuf_queue and task in struct ifnet with > a new ifiqueue structure modelled on ifqueues. > > the main motivation behind this was to show mpsafe input counters. > > ifiqueues, like ifqueu

multiple interface input queues

this replaces the single mbuf_queue and task in struct ifnet with a new ifiqueue structure modelled on ifqueues. the main motivation behind this was to show mpsafe input counters. ifiqueues, like ifqueues, allow a driver to configure multiple queueus. this in turn allows a driver with multiple

more ethernet media types

apparently active optical cables are distinct from direct attached cables, so here's a bunch of extra media types for them. you can also get LR and ER(?) optics for 25g. ok? Index: if_media.h === RCS file:

move reading of ifq counters for if_data into ifq.c

this moves the reading of counters out of an interfaces ifqs into ifq.c. there's no semantic change, i just want to keep the knowledge about locking in an ifq all in the same place. ok? Index: if.c === RCS file:

Re: try to bundle multiple packets on an ifq before sending

> On 13 Nov 2017, at 5:37 pm, Martin Pieuchot <m...@openbsd.org> wrote: > > On 13/11/17(Mon) 10:56, David Gwynne wrote: >> On Sun, Nov 12, 2017 at 02:45:05PM +0100, Martin Pieuchot wrote: >>> [...] >>> We're currently using net_tq() to distribute load for

Re: mbuf statistics, tracking of drops

On Sun, Nov 12, 2017 at 11:23:31PM +0100, Gregor Best wrote: > Hi Martin, > > On Sun, Nov 12, 2017 at 03:40:59PM +0100, Martin Pieuchot wrote: > > [...] > > It does, some comments below. > > [...] > > Wonderful. > > > [...] > > This would be an approximation because it might happen that after >

Re: try to bundle multiple packets on an ifq before sending

On Sun, Nov 12, 2017 at 02:45:05PM +0100, Martin Pieuchot wrote: > On 10/11/17(Fri) 10:58, David Gwynne wrote: > > this makes ifq_start try to wait for 4 packets before calling > > if->if_qstart. > > So you're adding back the IFXF_TXREADY mechanism that you rem

try to bundle multiple packets on an ifq before sending

this makes ifq_start try to wait for 4 packets before calling if->if_qstart. this is based on work sephe did in dragonflybsd, and described in a comment in their sys/net/if.c. there's a link to it here: https://github.com/DragonFlyBSD/DragonFlyBSD/blob/master/sys/net/if.c#L2976-L2987 the tests

Re: refill msk(4) rx ring from a timeout when there's no mbufs

theo pointed out the timeout should be cancelled when the interface goes down. this adds a timeout_del in msk_stop. some other drivers suffer this problem, ill have a look at them once this is in. On Mon, Oct 23, 2017 at 11:35:09AM +1000, David Gwynne wrote: > if msk runs out of mbufs, the

refill msk(4) rx ring from a timeout when there's no mbufs

if msk runs out of mbufs, the rx ring remains empty and there's nothing except an ifconfig down and up to get it going again. this adds a timeout to refill the ring. it's largely copied from other drivers (vr in this case). tests? ok? Index: if_mskvar.h

have netstart handle tap interfaces as well as tun

this helsp if you want to have a tap interface joined to a bridge on boot. ok? Index: netstart === RCS file: /cvs/src/etc/netstart,v retrieving revision 1.186 diff -u -p -r1.186 netstart --- netstart25 Jul 2017 21:17:11 -

move vmd vioblk ring processing to another thread

vmd currently performs disk io for the guest synchronously in the same thread the guest is running in. it also uses bounce buffers in between the guests "physical" memory and the read and writes against the disk image. this diff moves the vioblk ring processing into a taskq, ie, another thread.

Re: Remove DDB_STRUCTINFO

> On 11 Sep 2017, at 20:01, Martin Pieuchot wrote: > > Now that dlg@ implemented 'show struct' using CTF, which makes it > available in GENERIC kernel we can retire DDB_STRUCTINFO. > > Diff below does that, ok? it seems noone will miss the "show offset" command below, so ok.

Re: tftp: use monotonic clock for statistics summary

OK by me On 10 Sep. 2017 5:21 am, "Theo Buehler" wrote: > On Sat, Sep 09, 2017 at 04:28:45PM +, Scott Cheloha wrote: > > 3 week bump. > > looks good to me. > > anyone willing to ok this or commit this with my ok? > > > > > -- > > Scott Cheloha > > > > > On Aug 16,

Re: DMAC-driver, bus_dma & ofw_dmac

> On 2 Sep 2017, at 2:37 pm, Artturi Alm wrote: > > Hi, > > i've been slowly looking at bringing dma for some of the lesser sunxis, > and have reached the point where i'm unsure what to do next beyond > testing the functionality w/spreading SoC-specific hacks "for

allow cpumem_get (and pool_cache_init) earlier in boot

i wanted to enable per-cpu caches on the myx cluster pool, but the myx pool is set up before the cpumem subsystem is ready to back it. rather than add more hooks in myx, this has the cpumem subsystem init its own pool on the first use of it. it assumes ncpusfound will be correctly set before the

Re: RFC 7217: random but stable addresses (take 2)

> On 14 Jul 2017, at 06:30, Christian Weisgerber wrote: > > On 2017-07-13, Florian Obser wrote: > >> It switches the hash function to SipHash24 from sha512 as suggested by dlg > > It's for from clear to me whether SipHash is suitable for crypto >

Re: time(1): use monotonic clock for computing elapsed time

> On 13 Jul 2017, at 11:16 am, Scott Cheloha wrote: > > Hi, > > The "real" elapsed time for time(1) and the ksh/csh time builtins is > currently computed with gettimeofday(2), so it's subject to changes > by adjtime(2) and, if you're really unlucky, clock_settime(2) or

Re: first stab at RFC 7217: random but stable link local addresses

On Tue, Jul 11, 2017 at 11:48:47AM +, Florian Obser wrote: > On Tue, Jul 11, 2017 at 11:08:23AM +0100, Stuart Henderson wrote: > > On 2017/07/11 07:45, Florian Obser wrote: > > > The way I want to move forward with this is: > > > > > > 1) generate a random key at boot if it's not present yet

Re: Reduce pool cache items when there is no contention

> On 5 Jul 2017, at 20:11, Visa Hankala wrote: > > The current pool cache code increases the number of items that can be > cached locally in response to lock contention. This patch adds a tweak > that lowers the number when contention does not occur. The idea is to > let

Re: mpsafe malloc(9)

On Wed, Jul 05, 2017 at 09:44:19AM +1000, David Gwynne wrote: > the following adds a mutex to malloc and free to protect their > internal state. this should be enough to make the api mpsafe, > assuming the way they interact with uvm is mpsafe. > > this only uses a single mutex ar

s/Fifos/FIFOs/ in src/lib/libc/sys/kqueue.2

FIFO (not Fifo or fifo) is used everywhere else in the same page. Index: kqueue.2 === RCS file: /cvs/src/lib/libc/sys/kqueue.2,v retrieving revision 1.34 diff -u -p -r1.34 kqueue.2 --- kqueue.231 May 2017 14:52:05 - 1.34

mpsafe malloc(9)

the following adds a mutex to malloc and free to protect their internal state. this should be enough to make the api mpsafe, assuming the way they interact with uvm is mpsafe. this only uses a single mutex around the entire malloc subsystem, but shuffles the code slightly to avoid holding it

Re: bc makefile tweak

> On 4 Jul 2017, at 12:54, Michael W. Bombardieri wrote: > > Hi, > > When building bc, yacc can directly write bc.c instead of renaming > the file with mv. Does this look any better? there's some debate at the moment about the least worst or best way of handling this kind of

Re: dont use the malloc ks_limit in softdeps

hrm. ignore this. On Mon, Jul 03, 2017 at 04:30:11PM +1000, David Gwynne wrote: > the only thing using ks_limit is the ffs softdep code. > > this cleans that up. > > ok? > > Index: ffs/ffs_softdep.c > ===

dont use the malloc ks_limit in softdeps

the only thing using ks_limit is the ffs softdep code. this cleans that up. ok? Index: ffs/ffs_softdep.c === RCS file: /cvs/src/sys/ufs/ffs/ffs_softdep.c,v retrieving revision 1.135 diff -u -p -r1.135 ffs_softdep.c ---

tweak {event,evtimer,signal}_pending manpage

the timeval argument is not const. esp since thats how the remaining time is provided to the caller. ok? Index: event.3 === RCS file: /cvs/src/lib/libevent/event.3,v retrieving revision 1.52 diff -u -p -r1.52 event.3 --- event.3

Re: relayd/ctl alternative control socket

> On 23 Jun 2017, at 01:15, Kapetanakis Giannis > wrote: > > Hi, > > Here is a patch for using alternative control socket for relayd and relayctl. > It's based on ospfd. I would like for this to get in order to be able to > control multiple relayd daemons on

switch libkvm bits from hand rolled RBT updates to proper RBT api use

now RBT is in userland, we can actually use the API instead of hand rolling the copying of the tree topology. ok? Index: lib/libkvm/kvm_proc.c === RCS file: /cvs/src/lib/libkvm/kvm_proc.c,v retrieving revision 1.58 diff -u -p -r1.58

optimise uvm_map_fill_vmmap with a binary search

userland can ask for an array of a processes memory mappings via sysctl, starting from a specified point. currently that starting point is found by iterating over the mappings from start to finish, but because the mappings are in an RBT we can do a binary search instead. ok? Index: uvm_map.c

grow the number of pool items a cpu can cache on demand

the pool cache code counts the number of times the mutex on the global info was already held, which we can interpret as demand. in response to this demand we can grow the number of items a cpu can cache, which in return should reduce the codemand/contention on the global info. the contention is

gc idle pool cache lists

the diff below adds cleanup of idle lists in the cpu caches in pools. the caches on the cpus move lists of items around instead of individual items. these lists are moved to the global pool struct and accumulate there. if you get a burst of work in the pool (eg, you use a lot of mbufs for a short

tweak installer to use vnetid/parent for vlan config

the installer uses the vlan/vlandev ifconfig params to configure vlan interfaces. this updates it to use vnetid and parent. there's some semantic tweaks in here too. firstly, instead of creating a vlan interface so it can be selected to configure, this adds the next vlan interface to the list of

Re: pool cpu caches and a systat view of them

> On 14 Jun 2017, at 13:50, David Gwynne <da...@gwynne.id.au> wrote: > > i have a few things left to do in the pools per cpu caches, one of > which is make their activity visibile. to that end, here's a diff > provides a way for userland to request stats from the per c

pool cpu caches and a systat view of them

i have a few things left to do in the pools per cpu caches, one of which is make their activity visibile. to that end, here's a diff provides a way for userland to request stats from the per cpu caches, and uses that in systat so you can watch them. there are two added pool sysctls. one copies an

Re: ifconfig.8 doco for vnetid and parent options

On Wed, Jun 07, 2017 at 10:01:41AM +0100, Jason McIntyre wrote: > On Wed, Jun 07, 2017 at 05:58:42PM +1000, David Gwynne wrote: > > > > > > why not just add your one option to the vlan section, which is what it's > > > relevant to, for now. if in the future y

Re: ifconfig.8 doco for vnetid and parent options

On Wed, Jun 07, 2017 at 07:32:18AM +0100, Jason McIntyre wrote: > On Wed, Jun 07, 2017 at 02:51:42PM +1000, David Gwynne wrote: > > > > > > you are breaking the format of this page if you start to move specific > > > subsytems into the main body. > > &

Re: ifconfig.8 doco for vnetid and parent options

> On 6 Jun 2017, at 18:12, Jason McIntyre <j...@kerhand.co.uk> wrote: > > On Tue, Jun 06, 2017 at 11:56:28AM +1000, David Gwynne wrote: >> this adds doco for the parent options in ifconfig, and moves vnetid >> up into generic options list. >> >> th

ifconfig.8 doco for vnetid and parent options

this adds doco for the parent options in ifconfig, and moves vnetid up into generic options list. the vlan(4) specific doco has enough lies and omissions that id rather get rid of it. ok? Index: ifconfig.8 === RCS file:

Re: remove vlan specific ifconfig settings

00 problem that nobody > ever had ;-) i had the opposite problem where new vlan interfaces would collide with existing ones. > > But it is time to move on, we have to cope with it. > > So no objections anymore, OK reyk thank you. > >> Am 05.06.2017 um 07:28 schrieb

remove vlan specific ifconfig settings

vlan(4) handles the vnetid and ifparent ioctls, so we dont need the vlan specific handling. i previously removed the code that requests info with a vlan specific ioctl, but this removes the vlan settings code. there's a couple of semantic changes to note though. firstly, this aliases the "vlan",

make gem(4) transmit mpsafe

the interrupt handler is already marked mpsafe, but it took the kernel lock to handle the tx ring. this is mostly modelled on hints in ifq.h (which i wrote, so im biased). it avoids the use of atomic ops to keep track of the free space by using the producer and consumer like myx does, and

avoid ifq_deq_begin,commit,rollback in sxie(4/armv7)

i wrote this diff blind, so it may not compile or work. the intention is to check for space before attempting to dequeue a packet. the rest is largely cosmetic and makes it look more like a decent driver. could someone test please? Index: sxie.c

remove vlan(4) specific ifconfig output

the vlan specific output is redundant because vlan supports the generic vnetid and parent ioctls now. this leaves the code for setting vlan specific stuff because there's a slight semantic change i want to discuss separately. ifconfig output on a vlan interface changes a little like this:

Re: tweak msk to avoid ifq_deq_begin/commit/rollback

ll running concurrently. that's usually enough to tickle hairy drivers in my experience. do you want me to wait for you? or make it easier for you by putting it in now? dlg > > > > On 31 May 2017 01:29:06 David Gwynne <da...@gwynne.id.au> wrote: > >> ie, do the sp

Re: shorten ifconfig output for vnetids and parent interfaces

On Mon, May 29, 2017 at 03:34:51PM +1000, David Gwynne wrote: > this rolls vnetid and parent into a single encap line in ifconfig. > > eg: > > - vnetid: 7 > - parent: ix1 > + encap: vnetid: 7 parent: ix1 > > after this i would like to get rid of the

tweak msk to avoid ifq_deq_begin/commit/rollback

ie, do the space check before trying to dequeue and mbuf. this also moves it to using m_defrag. i dont have an msk plugged in and i dont know how to use the overdrive 1000 i have here. if someone could test and ok this, it would be great. Index: if_msk.c

Re: Prevent NET_LOCK() vs if_get() deadlock

i came up with what is effectively the same diff. ok by me. > On 29 May 2017, at 20:37, Martin Pieuchot wrote: > > As explained recently, calling refcnt_finalize() for ifp references and > sleeping while holding the NET_LOCK() creates a deadlock situation. > > However we can

shorten ifconfig output for vnetids and parent interfaces

this rolls vnetid and parent into a single encap line in ifconfig. eg: - vnetid: 7 - parent: ix1 + encap: vnetid: 7 parent: ix1 after this i would like to get rid of the vlan compat goo. ok? Index: ifconfig.c

better inline asm for spllower on hppa

this simplifies the asm in spllower. the trap that break forces to run reads the new cpl value out of arg0 (r26) and puts the old valud in r28 (ret0). the current asm is convoluted in how it gets the compiler to avoid those regs across the asm. right now it has gcc place the ncpl value in ret0,

Re: Fix for USB keyboards eating keys, a DDB story

> On 10 May 2017, at 23:22, Martin Pieuchot wrote: > > In 2001 augustss@NetBSD added the following hack to make USB keyboards > work in ddb(4): > > /* >* For the console keyboard we can't deliver CTL-ALT-ESC >* from the interrupt routine. Doing so would

Re: bypass support for iommu on sparc64

On Mon, May 08, 2017 at 11:03:58AM +1000, David Gwynne wrote: > on modern sparc64s (think fire or sparc enterprise Mx000 boxes), > setting up and tearing down the translation table entries (TTEs) > is very expensive. so expensive that the cost of doing it for disk > io has a noti

bypass support for iommu on sparc64

on modern sparc64s (think fire or sparc enterprise Mx000 boxes), setting up and tearing down the translation table entries (TTEs) is very expensive. so expensive that the cost of doing it for disk io has a noticable impact on compile times. now that there's a BUS_DMA_64BIT flag, we can use that

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