pcn(4): use ifq_dequeue instead of ifq_deq_begin/commit/rollback

2021-03-23 Thread David Gwynne
this follows the more standard order for fitting a packet onto a tx ring. it also uses the more modern m_defrag pattern for heavily fragmented packets. Works For Me(tm). ok? Index: if_pcn.c === RCS file:

Re: veb(4) exceeds 1514 byte frame size while bridge(4) doesn't?

2021-03-23 Thread David Gwynne
On Sun, Mar 21, 2021 at 04:24:24PM +0100, Jurjen Oskam wrote: > Hi, > > When trying out veb(4), I ran into a situation where TCP sessions across a > veb(4) bridge stalled while the exact same config using bridge(4) worked fine. > > After some investigation, it seems that veb(4) adds an FCS to

Re: ifconfig.8: document veb(4)

2021-03-11 Thread David Gwynne
> On 11 Mar 2021, at 8:06 pm, Klemens Nanni wrote: > > On Thu, Mar 11, 2021 at 01:46:34PM +1000, David Gwynne wrote: > >>> +.It Cm link0 >>> +Disable the filtering of 802.1Q VLAN and QinQ SVLAN packets. >>> +.It Cm -link0 >>> +Enable the

Re: ifconfig.8: document veb(4)

2021-03-10 Thread David Gwynne
> On 10 Mar 2021, at 23:07, Klemens Nanni wrote: > > On Tue, Mar 09, 2021 at 08:48:14PM +0100, Klemens Nanni wrote: >> Simple addition of VEB right before BRIDGE. > New diff sorting the section alphabetically between UMB and VLAN, > thanks jmc. > >> All text is copied from other already

Re: pcidump(8): add missing PCI classes

2021-03-05 Thread David Gwynne
ok. > On 5 Mar 2021, at 9:05 pm, Jan Klemkow wrote: > > Hi, > > this diff adds the missing PCI classes Accelerator and Instrumentation. > Thus, we can replace a few unknown in its output: > > - 0x0008: Class: 13 (unknown), Subclass: 00 (unknown), > + 0x0008: Class: 13

Re: rewritten vxlan(4)

2021-03-04 Thread David Gwynne
On Thu, Mar 04, 2021 at 03:36:19PM +1000, David Gwynne wrote: > as the subject says, this is a rewrite of vxlan(4). > > vxlan(4) relies on bridge(4) to implement learning, but i want to be > able to remove bridge(4) one day. while working on veb(4), i wrote > the guts of a

use 64bit ethernet addresses in carp(4)

2021-03-04 Thread David Gwynne
this passes the destination ethernet address from the network packet as a uint64_t from ether_input into carp_input, so it can use it to see if a carp interface should take the packet. it's been working on amd64 and sparc64. anyone else want to try? Index: netinet/ip_carp.c

work with 64bit ethernet addresses in ether_input()

2021-03-04 Thread David Gwynne
this applies the tricks with addresses from veb and etherbridge code to the normal ethernet input processing. it seems to make things a bit faster. some tests have shown a 15% improvement in forwarding performance with this diff. ive been running with it for the last week on sparc64 and amd64

rewritten vxlan(4)

2021-03-03 Thread David Gwynne
vision 1.82 diff -u -p -r1.82 if_vxlan.c --- net/if_vxlan.c 25 Feb 2021 02:48:21 - 1.82 +++ net/if_vxlan.c 4 Mar 2021 04:32:03 - @@ -1,7 +1,7 @@ -/* $OpenBSD: if_vxlan.c,v 1.82 2021/02/25 02:48:21 dlg Exp $ */ +/* $OpenBSD$ */ /* - * Copyright (c) 2013 Reyk

Re: veb(4) support for vmd(8)?

2021-02-28 Thread David Gwynne
> On 27 Feb 2021, at 10:11, Klemens Nanni wrote: > > On Sat, Feb 27, 2021 at 09:44:03AM +1000, David Gwynne wrote: >> >> >>> On 27 Feb 2021, at 7:50 am, Klemens Nanni wrote: >>> >>> On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wr

Re: veb(4) support for vmd(8)?

2021-02-26 Thread David Gwynne
> On 27 Feb 2021, at 9:57 am, Mike Larkin wrote: > > On Sat, Feb 27, 2021 at 09:44:03AM +1000, David Gwynne wrote: >> >> >>> On 27 Feb 2021, at 7:50 am, Klemens Nanni wrote: >>> >>> On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wr

Re: ip_fragment ip6_fragment

2021-02-26 Thread David Gwynne
I like it. I would like it more if you named the mbuf list variable "fml". ok by me. > On 26 Feb 2021, at 9:08 pm, Alexander Bluhm wrote: > > Hi, > > I always bothered me that ip_fragment() and ip6_fragment() behave > sligtly differently. Unify them and use an mlist to simplify the >

Re: veb(4) support for vmd(8)?

2021-02-26 Thread David Gwynne
> On 27 Feb 2021, at 7:50 am, Klemens Nanni wrote: > > On Sat, Feb 27, 2021 at 07:30:56AM +1000, David Gwynne wrote: >> i think this is enough to let vmd wire guests up to veb interfaces. > But please update vm.conf(5) to mention veb(4) and vport(4) in as well > SWITC

veb(4) support for vmd(8)?

2021-02-26 Thread David Gwynne
i think this is enough to let vmd wire guests up to veb interfaces. please remember that veb is not the same as bridge, so some care has to be taken when replacing bridge with veb. the biggest difference to note is that if you want the host to talk layer 3 (ie, ip, dhcp, etc) with the guests, the

Re: fix nvme(4): NULL deref. and empty device attachments

2021-02-24 Thread David Gwynne
ok > On 25 Feb 2021, at 02:34, Jan Klemkow wrote: > > Hi, > > While attaching the following disks, the nvme driver runs into a NULL > dereference in nvme_scsi_capacity16() and nvme_scsi_capacity(). > > nvme0 at pci1 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev > 0x00: msix,

Re: have m_copydata use a void * instead of caddr_t

2021-02-23 Thread David Gwynne
On Tue, Feb 23, 2021 at 01:09:06PM +0100, Alexander Bluhm wrote: > On Tue, Feb 23, 2021 at 07:31:30PM +1000, David Gwynne wrote: > > i'm not a fan of having to cast to caddr_t when we have modern > > inventions like void *s we can take advantage of. > > Shoud you remove al

have m_copydata use a void * instead of caddr_t

2021-02-23 Thread David Gwynne
i'm not a fan of having to cast to caddr_t when we have modern inventions like void *s we can take advantage of. ok? Index: share/man/man9/mbuf.9 === RCS file: /cvs/src/share/man/man9/mbuf.9,v retrieving revision 1.120 diff -u -p

Re: veb(4), a virtual ethernet bridge (that could replace bridge(4)?)

2021-02-22 Thread David Gwynne
> On 22 Feb 2021, at 12:46 am, Vitaliy Makkoveev wrote: > > Hello. > > >> +ifp->if_ioctl = veb_ioctl; >> +ifp->if_input = veb_input; >> +//ifp->if_rtrequest = veb_rtrequest; >> +ifp->if_output = veb_output; >> +ifp->if_enqueue = veb_enqueue; > > Could you replace c++

Re: Posted vs. non-posted device access

2021-02-15 Thread David Gwynne
> On 16 Feb 2021, at 06:01, Mark Kettenis wrote: > >> Date: Mon, 15 Feb 2021 01:19:29 +0100 >> From: Patrick Wildt >> >> Am Mon, Feb 15, 2021 at 09:55:56AM +1000 schrieb David Gwynne: >>> >>> >>>> On 15 Feb 2021, at 07:54, M

use rtalloc_mpath in pf_route{,6}

2021-02-15 Thread David Gwynne
if you have multiple links to the same destination, this will let you use them via route-to/reply-to/dup-to. ok? Index: pf.c === RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.1110 diff -u -p -r1.1110 pf.c --- pf.c

veb(4), a virtual ethernet bridge (that could replace bridge(4)?)

2021-02-14 Thread David Gwynne
orage *ss, void *port) +{ + struct ether_addr *endpoint = port; + struct sockaddr_dl *sdl; + + sdl = (struct sockaddr_dl *)ss; + sdl->sdl_len = sizeof(sdl); + sdl->sdl_family = AF_LINK; + sdl->sdl_index = 0; + sdl->sdl_type = IFT_ETHER; + sdl->

Re: Posted vs. non-posted device access

2021-02-14 Thread David Gwynne
> On 15 Feb 2021, at 07:54, Mark Kettenis wrote: > > One of the aspects of device access is whether CPU writes to a device > are posted or non-posted. For non-posted writes, the CPU will wait > for the device to acknowledge that the write has performed. If the > device sits on a bus far

Re: "monitoring only" interfaces

2021-02-14 Thread David Gwynne
On Sun, Feb 07, 2021 at 06:55:37PM +0100, Sebastian Benoit wrote: > David Gwynne(da...@gwynne.id.au) on 2021.01.27 17:13:09 +1000: > > some of the discussion around dup-to made me think that a diff we > > have here at work might be more broadly useful. > > > > we

Re: Unbound: add support for pf tables to ipset module

2021-02-07 Thread David Gwynne
On Sun, Feb 07, 2021 at 06:27:24PM +0100, Christopher Zimmermann wrote: > On Sun, Feb 07, 2021 at 04:20:26PM +, Stuart Henderson wrote: > > On 2021/02/07 17:04, Christopher Zimmermann wrote: > > > Hi, > > > > > > a year ago I added support for our pf tables to the unbound ipset module. > > >

Re: ifg_refcnt atomic operation

2021-02-05 Thread David Gwynne
refcnt_init starts counting at 1, while the existing code starts at 0. Do the crashes stop because we never fully release all the references and never free it now? On Sat, 6 Feb 2021, 10:55 Alexander Bluhm, wrote: > Hi, > > When I replace the ++ and -- of ifg_refcnt with an atomic operation, >

Re: have pf_route bail out if it resolves a route with RTF_LOCAL set

2021-02-04 Thread David Gwynne
On Fri, Jan 29, 2021 at 03:23:31PM +0100, Alexander Bluhm wrote: > On Fri, Jan 29, 2021 at 10:53:09AM +1000, David Gwynne wrote: > > > Are you sure that it does not break any use case? I have seen so > > > much strange stuff. What is the advantage? > > > > The c

Re: [External] : pf route-to: only run pf_test when packets enter and leave the stack

2021-02-02 Thread David Gwynne
On Tue, Feb 02, 2021 at 11:30:12AM +0100, Alexandr Nedvedicky wrote: > Hello, > > > On Tue, Feb 02, 2021 at 02:52:52PM +1000, David Gwynne wrote: > > > > however, like most things relating to route-to/reply-to/dup-to, im > > pretty sure at this point it's

pf route-to: only run pf_test when packets enter and leave the stack

2021-02-01 Thread David Gwynne
this is part of a high level discussion about when pf runs against a packet. the options are: 1. pf runs when a packet goes over an interface or 2. pf runs when a packet enters or leaves the network stack. for normal packet handling there isn't a difference between these options. in the routing

Re: have pf_route bail out if it resolves a route with RTF_LOCAL set

2021-01-28 Thread David Gwynne
On Thu, Jan 28, 2021 at 08:09:36PM +0100, Alexander Bluhm wrote: > On Thu, Jan 28, 2021 at 09:57:33AM +1000, David Gwynne wrote: > > calling if_output with a route to a local IP is confusing, and I'm not > > sure it makes sense anyway. > > > > this treats a an RTF_LOCAL

pf: route-to IPs, not interfaces

2021-01-28 Thread David Gwynne
this is the diff from the "pf route-to issues" thread, but on it's own. the summary of why i wanted to do this is: - route-to, reply-to, and dup-to do not work with pfsync this is because the information about where to route-to is stored in rules, and it is hard to have a ruleset synced

Re: have pf_route bail out if it resolves a route with RTF_LOCAL set

2021-01-27 Thread David Gwynne
On Thu, Jan 28, 2021 at 08:15:06AM +0100, Claudio Jeker wrote: > On Thu, Jan 28, 2021 at 09:57:33AM +1000, David Gwynne wrote: > > calling if_output with a route to a local IP is confusing, and I'm not > > sure it makes sense anyway. > > > > this treats a an RTF_LOCAL

handle PFRULE_ONCE before pfsync may defer tx of the packet

2021-01-27 Thread David Gwynne
i think these code chunks are around the wrong way. pfsync may want to defer the transmission of a packet. it does this so it can try and get a state over to a peer firewall before a host may send a reply to the peer, which would get dropped cos there's no matching state. i think the once rule

have pf_route bail out if it resolves a route with RTF_LOCAL set

2021-01-27 Thread David Gwynne
calling if_output with a route to a local IP is confusing, and I'm not sure it makes sense anyway. this treats a an RTF_LOCAL route like an invalid round and drops the packet. ok? Index: pf.c === RCS file: /cvs/src/sys/net/pf.c,v

"monitoring only" interfaces

2021-01-26 Thread David Gwynne
some of the discussion around dup-to made me think that a diff we have here at work might be more broadly useful. we run a box here with a bunch of ethernet ports plugged into span ports on switches. basically every packet going to our firewalls gets duplicated to this host. we then have code

if pf_route{,6} route isn't valid, generate an icmp error

2021-01-26 Thread David Gwynne
at the moment if the route is invalid, we drop the packet. this generates an icmp error. ok? Index: pf.c === RCS file: /cvs/src/sys/net/pf.c,v retrieving revision 1.1103 diff -u -p -r1.1103 pf.c --- pf.c27 Jan 2021 04:46:21

don't run dup-to generated packets through pf_test in pf_route{,6}

2021-01-26 Thread David Gwynne
this was discussed as part of the big route-to issues thread. i think it's easy to break out and handle separately now. the diff does what the subject line says. it seems to work as expected for me. i don't see weird state issues anymore when i dup my ssh session out over a tunnel interface.

Re: tiny pf_route{,6} tweak

2021-01-26 Thread David Gwynne
On Wed, Jan 27, 2021 at 11:13:12AM +1000, David Gwynne wrote: > when pf_route (and pf_route6) are supposed to handle forwarding the > packet (ie, for route-to or reply-to rules), they take the mbuf > away from the calling code path. this is done by clearing the mbuf > pointer in

tiny pf_route{,6} tweak

2021-01-26 Thread David Gwynne
when pf_route (and pf_route6) are supposed to handle forwarding the packet (ie, for route-to or reply-to rules), they take the mbuf away from the calling code path. this is done by clearing the mbuf pointer in the pf_pdesc struct. it doesn't do this for dup-to rules though. at the moment pf_route

Re: [External] : Re: pf route-to issues

2021-01-25 Thread David Gwynne
On Mon, Jan 25, 2021 at 05:38:40PM +0100, Alexandr Nedvedicky wrote: > Hello, > > > On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote: > > Hi, > > > > Some personal thoughts. I am happy when pf route-to gets simpler. > > Especially I have never understood what this

Re: [External] : Re: pf route-to issues

2021-01-25 Thread David Gwynne
On Mon, Jan 25, 2021 at 06:17:02PM +0100, Alexandr Nedvedicky wrote: > Hello, > > pf_route() might leak a refence to ifp. oh no :( > > Index: sys/net/pf.c > > === > > RCS file: /cvs/src/sys/net/pf.c,v > > retrieving revision 1.1101

Re: pf route-to issues

2021-01-25 Thread David Gwynne
On Mon, Jan 25, 2021 at 04:19:11PM +0100, Alexander Bluhm wrote: > On Fri, Jan 22, 2021 at 06:07:59PM +1000, David Gwynne wrote: > > --- sys/conf/GENERIC30 Sep 2020 14:51:17 - 1.273 > > +++ sys/conf/GENERIC22 Jan 2021 07:33:30 - > > @@ -82,6 +

Re: [External] : Re: pf route-to issues

2021-01-25 Thread David Gwynne
On Mon, Jan 25, 2021 at 03:21:29PM +0100, Alexander Bluhm wrote: > Hi, > > Some personal thoughts. I am happy when pf route-to gets simpler. > Especially I have never understood what this address@interface > syntax is used for. even after staring at it for so long, i still don't get it. i do

Re: [External] : Re: pf route-to issues

2021-01-25 Thread David Gwynne
On Mon, Jan 25, 2021 at 02:30:46PM +0100, Alexandr Nedvedicky wrote: > Hello, > > ... > > > > i dont understand the kif lifetimes though. can we just point a > > pdesc at an arbitrary kif or do we need ot reference count? > > > > as long as we don't release NET_LOCK() (or PF_LOCK() in

Re: [External] : Re: pf route-to issues

2021-01-25 Thread David Gwynne
On Mon, Jan 25, 2021 at 01:11:35PM +0100, Alexandr Nedvedicky wrote: > Hello, > > > > > > > > I understand that simple is better here, so I won't object > > > if we will lean towards simplified model above. However I still > > > would like to share my view on current PF. > > > > >

Re: [External] : Re: pf route-to issues

2021-01-24 Thread David Gwynne
On Mon, Jan 25, 2021 at 02:50:12AM +0100, Alexandr Nedvedicky wrote: > Hello, > > > > > ok. i don't know how to split up the rest of the change though. > > > > here's an updated diff that includes the rest of the kernel changes and > > the pfctl and pf.conf tweaks. > > > > it's probably useful

Re: [External] : Re: tell pfctl(8) route-to and reply-to accept next-hop only

2021-01-24 Thread David Gwynne
> On 25 Jan 2021, at 10:43, Alexandr Nedvedicky > wrote: > > hello, > > On Fri, Jan 22, 2021 at 05:32:47PM +1000, David Gwynne wrote: >> I tried this diff, and it broke the ability to use dynamic addresses. >> ie, the following rules should work: >>

Re: pf route-to issues

2021-01-22 Thread David Gwynne
On Fri, Jan 08, 2021 at 04:43:39PM +0100, Alexandr Nedvedicky wrote: > Hello, > > > > > > revision 1.294 > > date: 2003/01/02 01:56:56; author: dhartmei; state: Exp; lines: +27 -49; > > When route-to/reply-to is used in combination with address translation, > >

Re: tell pfctl(8) route-to and reply-to accept next-hop only

2021-01-21 Thread David Gwynne
I tried this diff, and it broke the ability to use dynamic addresses. ie, the following rules should work: pass in on gre52 inet proto icmp route-to (gre49:peer) pass in on vmx0 inet proto icmp route-to (gre:peer) however, other forms of dynamic interface addresses should fail. or do we want to

bpf(4) doesn't have to keep track of nonblocking state itself

2021-01-18 Thread David Gwynne
vfs does it for us. ok? Index: bpf.c === RCS file: /cvs/src/sys/net/bpf.c,v retrieving revision 1.202 diff -u -p -r1.202 bpf.c --- bpf.c 17 Jan 2021 02:27:29 - 1.202 +++ bpf.c 19 Jan 2021 00:10:22 - @@

bpf_mtap_ether doesnt need to encode packet priority

2021-01-14 Thread David Gwynne
bpf should be showing what will be or has been on the wire, which is what the ether_vtag in the mbuf has. the prio is either about to be decoded from the tag on the wya into the stack, or has been encoded by vlan(4) on the way out of the stack. ok? Index: bpf.c

Re: pf route-to issues

2021-01-05 Thread David Gwynne
On Mon, Jan 04, 2021 at 06:37:54PM +0100, Alexander Bluhm wrote: > On Mon, Jan 04, 2021 at 11:21:50PM +1000, David Gwynne wrote: > > this chunk pops out as a standalone change. > > > > having pf_find_state() return PF_PASS here means the callers short > > circuit an

Re: pf route-to issues

2021-01-04 Thread David Gwynne
On Mon, Jan 04, 2021 at 01:57:24PM +0100, Alexander Bluhm wrote: > On Mon, Jan 04, 2021 at 11:46:16AM +0100, Alexandr Nedvedicky wrote: > > > let's put this in and then i'll have a look. ok by me. > > bluhm's diff is fine with me. > > Refactoring is commited, here is the remaining kernel diff

Re: pf route-to issues

2021-01-04 Thread David Gwynne
> On 4 Jan 2021, at 9:27 pm, Alexandr Nedvedicky > wrote: > > Hello, > > there is one more thing, which just came up on my mind. > > >> >> so i want to change route-to in pfctl so it takes a nexthop instead >> of an interface. you could argue that pf already lets you do this, >> because

Re: pf route-to issues

2021-01-03 Thread David Gwynne
On Mon, Jan 04, 2021 at 12:58:17AM +0100, Alexander Bluhm wrote: > On Sun, Jan 03, 2021 at 06:56:20PM +0100, Alexander Bluhm wrote: > > I am currently running a full regress to find more fallout. > > These regress tests fail: > > sys/net/pf_forward > sys/net/pf_fragment > sbin/pfctl > > The

Re: pf route-to issues

2021-01-03 Thread David Gwynne
On Sun, Jan 03, 2021 at 06:56:20PM +0100, Alexander Bluhm wrote: > On Sun, Jan 03, 2021 at 02:00:00PM +1000, David Gwynne wrote: > > On Tue, Oct 20, 2020 at 09:27:09AM +1000, David Gwynne wrote: > > We've been running this diff in production for the last couple of > > months

Re: pf route-to issues

2021-01-02 Thread David Gwynne
On Tue, Oct 20, 2020 at 09:27:09AM +1000, David Gwynne wrote: > > i am feeling very warm and fuzzy about this diff at the moment. We've been running this diff in production for the last couple of months, and it's been solid for us so far. Ignoring the fixes for crashes, I personall

use stoeplitz to set flowids on tcp connections

2021-01-02 Thread David Gwynne
if stoeplitz is enabled by a driver (eg, ix, mcx, etc), this uses it in the tcp code to set the flowid on packets. this encourages both the tx and rx side of a tcp connection to get processed in the same places. ok? Index: netinet/in_pcb.c

Re: bpf(4): remove ticks

2020-12-28 Thread David Gwynne
On Mon, Dec 28, 2020 at 06:56:08PM -0600, Scott Cheloha wrote: > On Mon, Dec 28, 2020 at 10:49:59AM +1000, David Gwynne wrote: > > On Sat, Dec 26, 2020 at 04:48:23PM -0600, Scott Cheloha wrote: > > > Now that we've removed bd_rdStart from the bpf_d struct, removing > > &g

Re: bpf_catchpacket and bpf_wakeup optimisations

2020-12-28 Thread David Gwynne
On Mon, Dec 28, 2020 at 02:45:06PM +1000, David Gwynne wrote: > now that bpf read timeouts are only handled on the bpfread() side, > there's a simplification that can be made in bpf_catchpacket. the chunk > in bpf_catchpacket that rotates the buffers when one gets full already > does

Re: Fwd: gre(4): mgre

2020-12-28 Thread David Gwynne
On Sun, Nov 29, 2020 at 08:30:23PM +0100, Pierre Emeriaud wrote: > Le sam. 28 nov. 2020 ?? 21:46, Jason McIntyre a ??crit : > > > > > +.Bd -literal > > > > add "-offset indent" to match the other examples > > > Done, although I copied this block from gre example, so there's > > > another

bpf_catchpacket and bpf_wakeup optimisations

2020-12-27 Thread David Gwynne
now that bpf read timeouts are only handled on the bpfread() side, there's a simplification that can be made in bpf_catchpacket. the chunk in bpf_catchpacket that rotates the buffers when one gets full already does a wakeup, so we don't have to check if we have any waiting readers and wake them up

Re: bpf(4): remove ticks

2020-12-27 Thread David Gwynne
On Sat, Dec 26, 2020 at 04:48:23PM -0600, Scott Cheloha wrote: > Now that we've removed bd_rdStart from the bpf_d struct, removing > ticks from bpf(4) itself is straightforward. > > - bd_rtout becomes a timespec; update bpfioctl() accordingly. > Cap it at MAXTSLP nanoseconds to avoid arithmetic

Re: tht(4): more tsleep(9) -> tsleep_nsec(9) conversions

2020-12-16 Thread David Gwynne
ok > On 17 Dec 2020, at 04:22, Scott Cheloha wrote: > > On Thu, Dec 03, 2020 at 09:59:11PM -0600, Scott Cheloha wrote: >> Hi, >> >> tht(4) is another driver still using tsleep(9). >> >> It uses it to spin while it waits for the card to load the firmware. >> Then it uses it to spin for up to 2

Re: Lock operations for knote lists

2020-12-11 Thread David Gwynne
On Fri, Dec 11, 2020 at 05:37:57PM +, Visa Hankala wrote: > This patch extends struct klist with a callback descriptor and > an argument. The main purpose of this is to let the kqueue subsystem > assert when a klist should be locked, and operate the klist lock > in klist_invalidate(). i've

Re: diff: refactor MCLGETI() macro

2020-12-11 Thread David Gwynne
On Wed, Oct 07, 2020 at 10:44:15PM +0200, Jan Klemkow wrote: > Hi, > > The name of the macro MCLGETI obsolete. It was made to use a network > interface pointer inside. But, now it is just used to define a special > length and the interface pointer is discarded. > > Thus, the following diff

clear mbuf timestamp when it leaves the stack

2020-12-11 Thread David Gwynne
an mbuf timestamp is set by hw when a packet is rxed, and is then used by the socket layer and things like ntpd, but is also used by bpf when it provides packet timestamps. the timestamp is only valid on rxed packets though. when they leave the stack they should not be used anymore. on the way

Re: bgpd pftable change

2020-11-14 Thread David Gwynne
I've been using this for a week or so now and it's been very boring, which is an improvement in my experience. I has my ok if that has any value. dlg > On 9 Nov 2020, at 8:16 pm, Claudio Jeker wrote: > > Hi bgpd and esp. bgpd-spamd users, > > Currently the pftable code does not keep track

Re: net.inet.ip.forwarding=0 vs lo(4)

2020-10-19 Thread David Gwynne
On Mon, Oct 19, 2020 at 07:16:46PM +1000, David Gwynne wrote: > On Mon, Oct 19, 2020 at 10:03:29AM +0100, Stuart Henderson wrote: > > On 2020/10/19 11:47, David Gwynne wrote: > > > On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote: > > > > On 2020/1

Re: pf route-to issues

2020-10-19 Thread David Gwynne
On Mon, Oct 19, 2020 at 12:33:25PM +0100, Stuart Henderson wrote: > On 2020/10/19 19:53, David Gwynne wrote: > > On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote: > > > On 2020/10/19 15:35, David Gwynne wrote: > > > > every few years i try and use

Re: pf route-to issues

2020-10-19 Thread David Gwynne
On Mon, Oct 19, 2020 at 12:28:19PM +0200, Alexandr Nedvedicky wrote: > Hello, > > > > > > > > it seems to me 'route-to vs. pfsync' still needs more thought. the > > > next-hop IP address in route-to may be different for each PF box > > > linked by pfsync(4). To be honest I have no

Re: pf route-to issues

2020-10-19 Thread David Gwynne
On Mon, Oct 19, 2020 at 09:34:31AM +0100, Stuart Henderson wrote: > On 2020/10/19 15:35, David Gwynne wrote: > > every few years i try and use route-to in pf, and every time it > > goes badly. i tried it again last week in a slightly different > > setting, and actuall

Re: pf route-to issues

2020-10-19 Thread David Gwynne
On Mon, Oct 19, 2020 at 09:46:19AM +0200, Alexandr Nedvedicky wrote: > Hello, > > disclaimer: I have no chance to run pfsync on production, I'm very > inexperienced with pfsync(4). i wrote the defer code in pfsync, and i think i wrote the code in pfsync that calls pf_route badly, so noones

Re: net.inet.ip.forwarding=0 vs lo(4)

2020-10-19 Thread David Gwynne
On Mon, Oct 19, 2020 at 10:03:29AM +0100, Stuart Henderson wrote: > On 2020/10/19 11:47, David Gwynne wrote: > > On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote: > > > On 2020/10/18 14:04, David Gwynne wrote: > > > > the problem i'm hitting is that

pf route-to issues

2020-10-18 Thread David Gwynne
every few years i try and use route-to in pf, and every time it goes badly. i tried it again last week in a slightly different setting, and actually tried to understand the sharp edges i hit this time instead of giving up. it turns out there are 2 or 3 different things together that have cause me

Re: net.inet.ip.forwarding=0 vs lo(4)

2020-10-18 Thread David Gwynne
On Sun, Oct 18, 2020 at 08:57:34PM +0100, Stuart Henderson wrote: > On 2020/10/18 14:04, David Gwynne wrote: > > the problem i'm hitting is that i have a multihomed box where the > > service it provides listens on an IP address that's assigned to lo1. > > it's a host ru

net.inet.ip.forwarding=0 vs lo(4)

2020-10-17 Thread David Gwynne
this is mostly about discussion at the moment, i'm not tied to this diff at all. the problem i'm hitting is that i have a multihomed box where the service it provides listens on an IP address that's assigned to lo1. it's a host running a service, it's not a router, so the net.inet.ip.forwarding

Re: ifconfig: print tpmr(4) members

2020-08-04 Thread David Gwynne
> On 31 Jul 2020, at 17:17, Klemens Nanni wrote: > > This diff is to be applied on top of my other diff on tech@ with subject > "ifconfig: merge switch_status() into bridge_status()". > > It hooks completes the output of tpmr intefaces in what I think is the > simplest and least intrusive

Re: switch: allow datapath_id and maxflow ioctls for non-root

2020-08-04 Thread David Gwynne
> On 31 Jul 2020, at 14:28, Klemens Nanni wrote: > > ifconfig(8) detects switch(4) through its unique SIOCSWSDPID ioctl and > further does another switch specific ioctl for the default output > regardless of configuration and/or members: > > SIOCSWSDPID struct ifbrparam >

Re: ifconfig: merge switch_status() into bridge_status()

2020-08-04 Thread David Gwynne
> On 31 Jul 2020, at 16:36, Klemens Nanni wrote: > > On Wed, Jul 29, 2020 at 02:21:42PM +0200, Klemens Nanni wrote: >> This is to reduce duplicate code and pave the way for a single >> bridge_status() that covers all bridge like interfaces: bridge(4), >> switch(4) and tpmr(4). > A duplicate

Re: ifconfig: remove redundant bridge checks

2020-07-28 Thread David Gwynne
ok. > On 29 Jul 2020, at 11:38, Klemens Nanni wrote: > > On Tue, Jul 28, 2020 at 07:09:17PM +0200, Klemens Nanni wrote: >> bridge_status() and switch_status() do the regular sanity check with >> SIOCGIFFLAGS, but both functions also call is_switch(), bridge_status() >> also calls is_bridge().

Re: random toeplitz seeds

2020-07-17 Thread David Gwynne
On Fri, Jun 26, 2020 at 07:55:43AM +0200, Theo Buehler wrote: > This adds an stoeplitz_random_seed() function that generates a random > Toeplitz key seed with an invertible matrix T. This is necessary and > sufficient for the hash to spread out over all 65536 possible values. > > While it is

Re: mcx(4) RSS

2020-07-14 Thread David Gwynne
> On 14 Jul 2020, at 4:40 pm, Jonathan Matthew wrote: > > mcx(4) is almost ready to enable RSS, except arm64 doesn't yet support > mapping interrupts to cpus. Until that's in place, here's a diff with the > missing pieces from the driver in case anyone wants to test. This will > enable up

deprecate interface input handler lists, just use a single function pointer

2020-07-09 Thread David Gwynne
this diff is about fixing some semantic issues with the current interface input handler list processing. i was a bit worried it would cause a small performance hit, but it seems it has the opposite effect and is actually slightly faster. so in my opinion it is more correct, but also improves

Re: bridge(4) shouldn't try to create new interfaces when i make a typo

2020-07-09 Thread David Gwynne
> On 10 Jul 2020, at 12:45 am, sven falempin wrote: > > On Thu, Jul 9, 2020 at 3:31 AM Klemens Nanni wrote: >> >> On Thu, Jul 09, 2020 at 05:08:01PM +1000, David Gwynne wrote: >>> if i accidentally `ifconfig bridge add gre0` instead of egre0, having >>&g

Re: silicom X710 ixl, unable to query phy types, no sff

2020-07-09 Thread David Gwynne
ok. so the problem is the older api doenst support the "get phy types" command, or the sff commands. should we silence the "get phy types" error output? is there a better errno to use when the sff command isn't supported? should we add something to the manpage? should that something be "i'm

bridge(4) shouldn't try to create new interfaces when i make a typo

2020-07-09 Thread David Gwynne
if i accidentally `ifconfig bridge add gre0` instead of egre0, having bridge create gre0 and then not like it is not what i expect to happen. especially when it leaves me with an extra gre0 interface lying around afterwards. i can appreciate that this was trying to be helpful when you wanted to

let's not pretend switch(4) works with anything except ethernet interfaces.

2020-07-09 Thread David Gwynne
the code pretty obviously assumes that it only handles Ethernet packets, so we should restrict it to IF_ETHER type interfaces. ok? Index: if_switch.c === RCS file: /cvs/src/sys/net/if_switch.c,v retrieving revision 1.30 diff -u -p

kstats for em(4)

2020-07-07 Thread David Gwynne
this is a first pass at converting the stats gathering in em(4) to kstat instead of a disabled printf. there are some semantic differences. the most obvious is that hardware counters are not fed into the stacks counters on struct ifnet. i also don't collect ring based counters (yet). they look

Re: [patch] dhclient(8) crashes with vm.malloc_conf=J

2020-07-06 Thread David Gwynne
> On 7 Jul 2020, at 7:57 am, Jesper Wallin wrote: > > Hi all, > > I received a segmentation fault from dhclient(8) upon boot and decided > to investigate... My system is running with vm.malloc_conf=CFGJUR and > figured one of those options was the cause of the crash. I noticed that > the

Re: use libc base64 code instead of libcrypt for ifconfig wg key handling

2020-06-21 Thread David Gwynne
On Sun, Jun 21, 2020 at 07:15:15PM -0600, Theo de Raadt wrote: > In that case you can also delete: > > ifconfig.c:#include indeed i can. Index: Makefile === RCS file: /cvs/src/sbin/ifconfig/Makefile,v retrieving revision 1.16 diff

use libc base64 code instead of libcrypt for ifconfig wg key handling

2020-06-21 Thread David Gwynne
libc has undocumented base64 encoding and decoding funtionality. this cuts ifconfig over to using it instead of the code in libcrypto. whether the libc functionality should be "blessed" and documented is a separate issue. ok? Index: Makefile

Re: WireGuard patchset for OpenBSD, rev. 3

2020-06-21 Thread David Gwynne
On Sun, Jun 21, 2020 at 12:52:53PM +0200, Matthieu Herrb wrote: > On Fri, Jun 19, 2020 at 06:46:00PM +1000, Matt Dunwoodie wrote: > > Hi all, > > > > After the previous submission of WireGuard, we've again been through a > > number of improvements. Thank you everyone for your feedback. > > Hi, >

deprecate softclock based network livelock detection

2020-06-19 Thread David Gwynne
the network stack doesnt really block timeouts from firing anymore. this is especially true on MP systems, because timeouts fire on cpu0 and the nettq thread could be somewhere else entirely. this means network activity doesn't make the softclock lose ticks, which means we aren't scaling rx ring

Re: multiple rings and cpus for ix(4)

2020-06-19 Thread David Gwynne
. 11:27, Hrvoje Popovski wrote: > >>>> On 17.6.2020. 10:36, David Gwynne wrote: > >>>>> this is an updated version of a diff from christiano haesbaert by way of > >>>>> mpi@ to enable the use of multiple tx and rx rings with msi-x. > >>>>> > >

Re: stoeplitz_hash_ip*: rename lo & simplify further

2020-06-18 Thread David Gwynne
> On 18 Jun 2020, at 7:49 pm, Theo Buehler wrote: > > The same trick as in the previous diff can be used a second time: > widen the type, accumulate before folding. > > I've also shuffled things into an order where the introduction of > a stoeplitz_hash_n32(scache, n32) suggests itself as a

Re: stoeplitz_hash_ip*: avoid early split into hi and lo

2020-06-17 Thread David Gwynne
> On 18 Jun 2020, at 2:34 pm, Theo Buehler wrote: > > Now that the calls to stoeplitz_cache_entry() are out of the way, > we can avoid half of the calculations by merging the computation of > hi and lo, only spliting at the end. This allows us to leverage > stoeplitz_hash_n16(). > > The

Re: simplify stoeplitz_hash_ip*

2020-06-17 Thread David Gwynne
> On 18 Jun 2020, at 1:34 am, Theo Buehler wrote: > > The next step is to use that we have cached the result of the matrix > multiplication H * val in stoeplitz_cache_entry(scache, val), so the > identity (H * x) ^ (H * y) == H * (x ^ y) allows us to push the calls to > the cache function

multiple rings and cpus for ix(4)

2020-06-17 Thread David Gwynne
this is an updated version of a diff from christiano haesbaert by way of mpi@ to enable the use of multiple tx and rx rings with msi-x. the high level description is that that driver checks to see if msix is available, and if so how many vectors it has. it then gets an intrmap based on that

Re: simplify Toeplitz cache computation

2020-06-16 Thread David Gwynne
> On 17 Jun 2020, at 01:57, Theo Buehler wrote: > > The diff below removes some of the unnecessary complications in the > calculation of the stoeplitz_cache and brings them into a form more > suitable for mathematical reasoning. I added a somewhat dense comment > which explains the full

interrupt to cpu mapping API

2020-06-15 Thread David Gwynne
16 Jun 2020 00:13:50 - @@ -0,0 +1,125 @@ +.\" $OpenBSD$ +.\" +.\" Copyright (c) 2020 David Gwynne +.\" +.\" Permission to use, copy, modify, and distribute this software for any +.\" purpose with or without fee is hereby granted, provided that the above +.\&q

  1   2   3   4   5   6   7   8   9   10   >