Re: em(4) multiqueue

2022-07-02 Thread David Gwynne
> On 2 Jul 2022, at 08:44, Hrvoje Popovski wrote: > > On 28.6.2022. 15:11, Jonathan Matthew wrote: >> This adds the (not quite) final bits to em(4) to enable multiple rx/tx >> queues. >> Note that desktop/laptop models (I218, I219 etc.) do not support multiple >> queues, >> so this only

Re: start unlocking kbind(2)

2022-06-11 Thread David Gwynne
On Tue, May 31, 2022 at 04:48:16PM +0200, Martin Pieuchot wrote: > On 18/05/22(Wed) 15:53, Alexander Bluhm wrote: > > On Tue, May 17, 2022 at 10:44:54AM +1000, David Gwynne wrote: > > > + cookie = SCARG(uap, proc_cookie); > > > +

Re: start unlocking kbind(2)

2022-06-11 Thread David Gwynne
On Wed, May 18, 2022 at 07:42:32PM -0600, Theo de Raadt wrote: > Mark Kettenis wrote: > > > > Isn't the vm_map_lock enough? > > > > Could be. The fast path is going to take that lock anyway. This > > would require a bit of surgery to uvm_map_extract() to make sure we > > don't take the

Re: ix(4): Add support for TCP Large Receive Offloading

2022-06-10 Thread David Gwynne
> On 10 Jun 2022, at 08:24, Hrvoje Popovski wrote: > > On 9.6.2022. 19:25, Hrvoje Popovski wrote: >> On 9.6.2022. 19:11, Jan Klemkow wrote: >>> On Thu, Jun 09, 2022 at 08:25:22AM +0200, Hrvoje Popovski wrote: On 8.6.2022. 22:01, Hrvoje Popovski wrote: > On 8.6.2022. 15:04, Jan

unlock pf_purge

2022-06-07 Thread David Gwynne
the main change here is to move pf_purge out from under the kernel lock. another part of the change is to limit the amount of work the state purging does to avoid hogging a cpu too much, and to also avoid holding NET_LOCK for too long. the main part is acheived by using systqmp to run the purge

Re: relayd panic

2022-06-06 Thread David Gwynne
> On 6 Jun 2022, at 18:08, Claudio Jeker wrote: > > On Mon, Jun 06, 2022 at 12:03:06AM +0200, Alexandr Nedvedicky wrote: >> Hello, >> >> I'll commit one-liner diff on Tuesday morning (Jun 6th) Prague time without >> explicit OK, unless there will be no objection. > > The diff is OK

Re: Fix clearing of sleep timeouts

2022-06-05 Thread David Gwynne
On Sun, Jun 05, 2022 at 03:57:39PM +, Visa Hankala wrote: > On Sun, Jun 05, 2022 at 12:27:32PM +0200, Martin Pieuchot wrote: > > On 05/06/22(Sun) 05:20, Visa Hankala wrote: > > > Encountered the following panic: > > > > > > panic: kernel diagnostic assertion "(p->p_flag & P_TIMEOUT) == 0"

Re: mvsw(4): present each port as a separate interface

2022-06-01 Thread David Gwynne
here's an updated diff. the main changes are: 1. disable the phy code. letting eephy attach seems to break autonegotiation. it also looks like several generations of the marvell switches don't supply a proper model id for the builtin phy, so the linux driver fakes one and has extra code in

Re: mvsw(4): present each port as a separate interface

2022-05-30 Thread David Gwynne
On Mon, May 30, 2022 at 09:14:47PM +0200, Mark Kettenis wrote: > > Date: Sat, 28 May 2022 15:08:49 +1000 > > From: David Gwynne > > > > the espressobin is the least worst thing ive settled on. it's not > > too expensive, it has a case, it has multiple interfaces

mvsw(4): present each port as a separate interface

2022-05-27 Thread David Gwynne
ive been hunting for a small box, ie, it has a case, with at least two (non usb) gig interfaces for use/recommend as a cheap and cheerful home router, and it feels like trying to find a unicorn sometimes. i was looking at ipq4018/ipq4019 devs for a while, but ive been turned off those systems

Re: ix(4): Add support for TCP Large Receive Offloading

2022-05-27 Thread David Gwynne
On Fri, May 27, 2022 at 06:25:00PM +0200, Jan Klemkow wrote: > Hi, > > The following diff enables the TCP Large Receive Offloading feature for > ix(4) interfaces. It also includes a default off sysctl(2) switch. > > The TCP single stream receiving performance increased from 3.6 Gbit/s to > 9.4

Re: start unlocking kbind(2)

2022-05-18 Thread David Gwynne
On Tue, May 17, 2022 at 10:14:18AM -0600, Theo de Raadt wrote: > Martin Pieuchot wrote: > > > On 17/05/22(Tue) 10:44, David Gwynne wrote: > > > this narrows the scope of the KERNEL_LOCK in kbind(2) so the syscall > > > argument checks can be done without the

start unlocking kbind(2)

2022-05-16 Thread David Gwynne
this narrows the scope of the KERNEL_LOCK in kbind(2) so the syscall argument checks can be done without the kernel lock. care is taken to allow the pc/cookie checks to run without any lock by being careful with the order of the checks. all modifications to the pc/cookie state are serialised by

have in6_pcbselsrc copy the selected ip to the caller instead of a reference

2022-05-15 Thread David Gwynne
this is basically the same as what i did for in_pcbselsrc, and completely mechanical. im too tired to figure out if there's a smarter way to do it. lightly tested, and more eyes are welcome because of the tiredness thing. Index: in6_pcb.c

Re: beef up ksmn(4) to show more temps and CPU frequency

2022-04-24 Thread David Gwynne
On Sun, Apr 24, 2022 at 11:32:53PM +0200, Claudio Jeker wrote: > On Sun, Apr 24, 2022 at 02:30:37PM -0400, Bryan Steele wrote: > > On Sun, Apr 24, 2022 at 07:06:19PM +0200, Claudio Jeker wrote: > > > On Ryzen CPUs each CCD has a temp sensor. If the CPU has CCDs (which > > > excludes Zen APU CPUs)

kstats for re(4)

2022-04-22 Thread David Gwynne
re(4) hardware has some useful counters that are worth looking at: dlg@router ~$ kstat re-stats re0:0:re-stats:0 TxOk: 12697 packets RxOk: 22919 packets TxEr: 0 packets RxEr: 0 packets MissPkt: 0 packets FAE: 8371 packets

Re: pfsync debug bye-bye

2022-04-20 Thread David Gwynne
> On 21 Apr 2022, at 02:14, Alexander Bluhm wrote: > > Hi, > > In pfsync there are some KASSERT hidden behind #ifdef PFSYNC_DEBUG. > That does not make sense to me. Either they are correct, then they > should actively check in production. Or they got wrong over time, > then they should not

Re: ure(4): add support for RTL8156B

2022-04-01 Thread David Gwynne
> On 2 Apr 2022, at 03:09, Stuart Henderson wrote: > > On 2022/04/01 17:13, Stuart Henderson wrote: >> On 2022/04/01 10:26, Gerhard Roth wrote: >>> On 4/1/22 07:41, Kevin Lo wrote: ure0: RTL8153 (0x5c10), address 00:e0:4c:xx:xx:xx rgephy1 at ure0 phy 0: RTL8251 PHY, rev. 0

Re: CMSG_DATA(3): add an example for receiving mulitple control messages

2022-03-22 Thread David Gwynne
On Tue, Mar 22, 2022 at 09:12:23AM +0100, Claudio Jeker wrote: > On Tue, Mar 22, 2022 at 02:24:25PM +1000, David Gwynne wrote: > > i couldnt find any good examples of what to do when you wanted to > > receive multiple control messages from a single recvmsg call. the most > > i

CMSG_DATA(3): add an example for receiving mulitple control messages

2022-03-21 Thread David Gwynne
i couldnt find any good examples of what to do when you wanted to receive multiple control messages from a single recvmsg call. the most interesting bit is how much space the buffer needs to be. if i struggled maybe someone else will too? Index: CMSG_DATA.3

Re: aarch64 I2C usage on Raspberry Pi 4B

2022-03-21 Thread David Gwynne
are you trying to add an i2c device to the sensor framework? or are you asking how to touch i2c devices from userland? > On 21 Mar 2022, at 16:21, Dr. T.I.S. wrote: > > I know the rule, try to research first on man pages, openbsd.org, ect, > and ask people as a last resort. Unfortunately, I

have in_pcbselsrc copy the selected ip to the caller instead of a reference to it

2022-03-20 Thread David Gwynne
in_pcbselsrc has this: ifp = if_get(mopts->imo_ifidx); if (ifp != NULL) { if (ifp->if_rdomain == rtable_l2(rtableid)) IFP_TO_IA(ifp, ia); if (ia == NULL) {

Re: atomic read write

2022-03-10 Thread David Gwynne
On Thu, Mar 10, 2022 at 10:45:47AM +, Laurence Tratt wrote: > On Thu, Mar 10, 2022 at 09:05:54AM +, Visa Hankala wrote: > > Hello Visa, > > > In general, atomic_* functions have not provided implicit memory > > barriers on OpenBSD. > > I've used atomics fairly extensively in other

Re: atomic read write

2022-03-10 Thread David Gwynne
On Thu, Mar 10, 2022 at 10:26:21PM +, Laurence Tratt wrote: > On Thu, Mar 10, 2022 at 09:52:27PM +0100, Mark Kettenis wrote: > > Hello Mark, > > > If you think about it, the invariants being tested by those KASSERTs should > > not depend on whether the old or the new value is read if another

Re: assert "sc->sc_dev == NUM" failed in if_tun.c (2)

2022-02-24 Thread David Gwynne
On Thu, Feb 24, 2022 at 11:13:48AM +0100, Claudio Jeker wrote: > On Thu, Feb 24, 2022 at 07:39:54PM +1000, David Gwynne wrote: > > > > here's the diff. > > > > Index: if_tun.c > > === > >

Re: assert "sc->sc_dev == NUM" failed in if_tun.c (2)

2022-02-24 Thread David Gwynne
On Mon, Feb 21, 2022 at 03:00:01PM +1000, David Gwynne wrote: > On Sun, Feb 20, 2022 at 10:30:22AM +1000, David Gwynne wrote: > > > > > > > On 20 Feb 2022, at 09:46, David Gwynne wrote: > > > > > > On Sat, Feb 19, 2022 at 02:58:08PM -0800, Greg

ifconfig(8): always print the mtu, don't hide it on "bridges"

2022-02-21 Thread David Gwynne
this lets ifconfig show the MTU on interfaces like nvgre, vxlan, etc. they currently don't show it because they also implement a bridge ioctl, so ifconfig thinks they're a bridge. why ifconfig hides the mtu on bridges looks to be a hold over from when brconfig was merged into ifconfig. if we dont

Re: rewritten vxlan(4)

2022-02-14 Thread David Gwynne
On Fri, Feb 11, 2022 at 03:13:25PM +1000, David Gwynne wrote: > On Fri, Mar 05, 2021 at 05:09:29PM +1000, David Gwynne wrote: > > On Thu, Mar 04, 2021 at 03:36:19PM +1000, David Gwynne wrote: > > > as the subject says, this is a rewrite of vxlan(4). > > > > &

Re: Adjust bpf event filter

2022-02-14 Thread David Gwynne
On Mon, Feb 14, 2022 at 08:34:42AM +, Visa Hankala wrote: > This makes bpf(4) use knote_modify_fn() and knote_process_fn(). > > Since the code has only one event function, it makes sense to use it > directly instead of going through struct filterops f_event pointer. > > OK? ok. > > Index:

check pf rule set prio values consistently in the pf ioctl code

2022-02-14 Thread David Gwynne
consistently means we do the check in pf_rule_copyin() so both DIOCADDRULE and DIOCCHANGERULE have the prio values checked. this in turn prevents invalid prio values getting set on a rule via DIOCCHANGERULE, which in turn stops a kassert in the ifq priq code firing. i think this fixes

prevent opening of dead tun/tap devices

2022-02-14 Thread David Gwynne
if an open tun (or tap) device is destroyed via ifconfig destroy, there is a window while the open device is being revoked on the vfs side that a third thread can come and open it again. this in turn triggers a kassert in the ifconfig destroy path where it expects the device to be closed. i think

Re: rewritten vxlan(4)

2022-02-10 Thread David Gwynne
On Fri, Mar 05, 2021 at 05:09:29PM +1000, David Gwynne wrote: > 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

Re: hardware checksum ix and ixl

2022-02-09 Thread David Gwynne
On Wed, Jan 26, 2022 at 01:29:42AM +0100, Alexander Bluhm wrote: > Hi, > > There were some problems with ix(4) and ixl(4) hardware checksumming > for the output path on strict alignment architectures. > > I have merged jan@'s diffs and added some sanity checks and > workarounds. > > - If the

Re: hardware checksum ix and ixl

2022-02-07 Thread David Gwynne
On Mon, Feb 07, 2022 at 02:39:38PM +1000, David Gwynne wrote: > On Fri, Feb 04, 2022 at 09:29:56PM +1000, David Gwynne wrote: > > On Fri, Jan 28, 2022 at 05:26:01PM +0100, Alexander Bluhm wrote: > > > On Wed, Jan 26, 2022 at 11:05:51AM +0100, Claudio Jeker wrote: > > > &

Re: hardware checksum ix and ixl

2022-02-06 Thread David Gwynne
On Fri, Feb 04, 2022 at 09:29:56PM +1000, David Gwynne wrote: > On Fri, Jan 28, 2022 at 05:26:01PM +0100, Alexander Bluhm wrote: > > On Wed, Jan 26, 2022 at 11:05:51AM +0100, Claudio Jeker wrote: > > > On Wed, Jan 26, 2022 at 01:29:42AM +0100, Alexander Bluhm

Re: convert bgpd to stdint.h types

2022-02-04 Thread David Gwynne
ok On Sat, 5 Feb 2022, 01:08 Claudio Jeker, wrote: > This is something I wanted to do for a while. Switch from u_intXY_t to > uintXY_t from stdint.h. The diff is mostly mechanical and was done with > sed -i 's/u_intX_t/uintX_t/g' but uint8_t changes the tab spacing and so > I had a look over

Re: always align data in m_pullup on all archs

2022-02-04 Thread David Gwynne
On Fri, Feb 04, 2022 at 11:39:56AM +0100, Alexander Bluhm wrote: > On Fri, Feb 04, 2022 at 07:32:52PM +1000, David Gwynne wrote: > > as discussed in "m_pullup alingment crash armv7 sparc64", at worst it > > doesnt hurt to have m_pullup maintain the data alignment of

Re: openbgpd vs illumos

2022-02-04 Thread David Gwynne
Ok On Fri, 4 Feb 2022, 21:19 Claudio Jeker, wrote: > On illumos sun is defined by some header so better not use sun as a > variable name. Rename variable to sa_un to reduce hacks in -portable. > > -- > :wq Claudio > > Index: bgpctl/bgpctl.c >

Re: hardware checksum ix and ixl

2022-02-04 Thread David Gwynne
On Fri, Jan 28, 2022 at 05:26:01PM +0100, Alexander Bluhm wrote: > On Wed, Jan 26, 2022 at 11:05:51AM +0100, Claudio Jeker wrote: > > On Wed, Jan 26, 2022 at 01:29:42AM +0100, Alexander Bluhm wrote: > > > Hi, > > > > > > There were some problems with ix(4) and ixl(4) hardware checksumming > > >

always align data in m_pullup on all archs

2022-02-04 Thread David Gwynne
as discussed in "m_pullup alingment crash armv7 sparc64", at worst it doesnt hurt to have m_pullup maintain the data alignment of payloads, and at best it will encourage aligned loads even if the arch allows unaligned accesses. aligned loads are faster than unaligned. ok? Index: uipc_mbuf.c

Re: m_pullup alingment crash armv7 sparc64

2022-02-04 Thread David Gwynne
On Thu, Feb 03, 2022 at 11:39:50PM +0100, Alexander Bluhm wrote: > On Thu, Feb 03, 2022 at 10:22:46PM +1000, David Gwynne wrote: > > bpf should know better than this. it has all the information it needs to > > align the payload properly, it just doesnt make enough of an effort.

Re: m_pullup alingment crash armv7 sparc64

2022-02-03 Thread David Gwynne
On Wed, Feb 02, 2022 at 10:30:24PM +0100, Alexander Bluhm wrote: > Hi, > > With the new m_pullup() code, I see crashes on armv7 and sparc64. > regress/sbin/slaacd sends some IPv6 ND6 packets over pair(4) from > scapy. It crashes after m_pullup() in ipv6_check(). > > run-parse-ra >

Re: don't try and wakeup select/poll/kq in tun/bpf close

2022-01-15 Thread David Gwynne
On Sun, Jan 16, 2022 at 06:17:16AM +, Visa Hankala wrote: > On Sun, Jan 16, 2022 at 02:41:46PM +1000, David Gwynne wrote: > > if you're in bpfclose or tun/tap close, you're the last one out. this > > means that there shouldn't be anything else in poll/select/kevent/etc >

don't try and wakeup select/poll/kq in tun/bpf close

2022-01-15 Thread David Gwynne
if you're in bpfclose or tun/tap close, you're the last one out. this means that there shouldn't be anything else in poll/select/kevent/etc because you're the last one out. from what i can tell, tun and bpf are the only drivers that do this, and i dont think they need to. ok? Index: bpf.c

msk(4): handle status ring entries as a single 64bit word

2022-01-05 Thread David Gwynne
and then shift and mask the interesting bits out. this works on an overdrive 1000, where i discovered that arm64 appears to have a single instruction for shift/mask. maybe too much churn to be worth it? Index: if_msk.c === RCS

msk(4) txeof should use completion indexes from status descriptors

2022-01-04 Thread David Gwynne
this is what i want to commit to fix "msk(4) not working with trunk(4) (Marvell Yukon 88E8042)" as reported on bugs@. the register that msk_txeof currently uses to figure out where it should read up to appears to be more a counter than an actual index. the linux driver doesnt use it though, it

tcpdump: basic parsing of EAPOL PDUs

2022-01-03 Thread David Gwynne
i was trying to understand some packets that tcpdump didnt know about, and discovered they were EAPOL. turns out EAPOL is a little container around a bunch of different types of messages including EAP, the MACsec Key Agreement protocol, and it's own type of capabilities advertisements. this

Re: explain priority codepoints and their mapping in vlan.4

2021-12-20 Thread David Gwynne
are you able to find a reference for this in any of the current specs? or in documentation from other vendors? i've faithfully maintained this behaviour, but the only place i've seen in with my own eyes is in our code. if we're doing it different to literally everyone else, then maybe we

Re: vport: set UP on ip assign

2021-11-15 Thread David Gwynne
On Mon, Nov 15, 2021 at 02:31:42PM +, Klemens Nanni wrote: > On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote: > > On 2021/11/15 12:27, Klemens Nanni wrote: > > > On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote: > > > > I think physical interfaces should come up

Re: let dhcpd start on down interfaces

2021-11-15 Thread David Gwynne
On Mon, Nov 15, 2021 at 12:19:48PM +, Klemens Nanni wrote: > On Mon, Nov 15, 2021 at 02:08:33PM +1000, David Gwynne wrote: > > The subject line only tells half the story. The other half is that > > instead of hoping it only identifies Ethernet interfaces it now actu

let dhcpd start on down interfaces

2021-11-14 Thread David Gwynne
The subject line only tells half the story. The other half is that instead of hoping it only identifies Ethernet interfaces it now actually checks and restricts itself to Ethernet interfaces. I couldn't help myself. If it helps my case for this code, I've been using this semantic for a few years

Re: vport: set UP on ip assign

2021-11-14 Thread David Gwynne
On Sat, Nov 13, 2021 at 11:59:59PM +, Klemens Nanni wrote: > Practically all interfaces pull itself up when IPs get assigned, but > vport(4) does not. Yes, I do (or don't do) this very deliberately when I get the chance. > This broke IPv4 networking for me on a router I switched from

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-28 Thread David Gwynne
On Thu, Oct 28, 2021 at 03:43:11PM +0100, Jason McIntyre wrote: > On Thu, Oct 28, 2021 at 04:53:39PM +1000, David Gwynne wrote: > > > > > > > On 28 Oct 2021, at 15:35, Jason McIntyre wrote: > > > > > > On Thu, Oct 28, 2021 at 01:27:17PM +1000, David G

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-28 Thread David Gwynne
On Thu, Oct 28, 2021 at 04:06:39PM +0100, Stuart Henderson wrote: > On 2021/10/28 13:11, David Gwynne wrote: > > On Wed, Oct 27, 2021 at 10:12:35AM +0100, Stuart Henderson wrote: > > > On 2021/10/27 17:44, David Gwynne wrote: > > > > > > > > >

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-28 Thread David Gwynne
> On 28 Oct 2021, at 15:35, Jason McIntyre wrote: > > On Thu, Oct 28, 2021 at 01:27:17PM +1000, David Gwynne wrote: >> >>> that strategy does rely on individual driver docs saying upfront that >>> they can be created though, even if using create is not

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-27 Thread David Gwynne
On Wed, Oct 27, 2021 at 02:32:31PM +0100, Jason McIntyre wrote: > On Wed, Oct 27, 2021 at 10:12:35AM +0100, Stuart Henderson wrote: > > On 2021/10/27 17:44, David Gwynne wrote: > > > > > > > benno@ suggested I look at vether(4) to adapt the text related to > >

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-27 Thread David Gwynne
On Wed, Oct 27, 2021 at 10:12:35AM +0100, Stuart Henderson wrote: > On 2021/10/27 17:44, David Gwynne wrote: > > > > > benno@ suggested I look at vether(4) to adapt the text related to > > > bridge(4) but I'm not sure how to rewrite it properly for veb(4). > > &g

Re: demystify vport(4) in vport(4) and ifconfig(8)

2021-10-27 Thread David Gwynne
On Wed, Oct 27, 2021 at 08:34:48AM +0200, Solene Rapenne wrote: > On Wed, 27 Oct 2021 07:28:32 +1000 > David Gwynne : > > > On Tue, Oct 26, 2021 at 09:18:30PM +0200, Solene Rapenne wrote: > > > I tried to figure out how to use veb interfaces but the man page > &g

Re: demystify vport(4) in vport(4) and ifconfigt(8)

2021-10-26 Thread David Gwynne
On Tue, Oct 26, 2021 at 09:18:30PM +0200, Solene Rapenne wrote: > I tried to figure out how to use veb interfaces but the man page > wasn't obvious in regards to the "vport" thing. It turns out it's > a kind of interface that can be created with ifconfig. > > I think we should make this clearer.

fix uchcom(4) handling of parity and character size config

2021-10-26 Thread David Gwynne
i bought some random usb to rs485 serial adapters so i can talk modbus to a thing, but then discovered i can't talk to the modbus thing because uchcom doesn't support configuring parity. this ports the functionality to support configuring parity and char size masks from netbsd

Re: teach pf to refragment ipv4 packets

2021-08-31 Thread David Gwynne
lution fixes a DF problem, and makes the no-df option > superfluous, and works out of the box, we can consider implementing > it for DF packets. I'll have to think about that for a bit. > > bluhm > > On Tue, Aug 31, 2021 at 10:56:34PM +1000, David Gwynne wrote: > > i am in

teach pf to refragment ipv4 packets

2021-08-31 Thread David Gwynne
i am in an annoying situation where i peer with a campus network on an ospf link with a 9k mtu, but some corners of that network have layer 2 hops that don't support 9k packets. i sometimes want to tunnel large (1500 byte) packets to hosts in those corners of the network by letting the

Re: [External] : better use the tokeniser in the pfctl parser

2021-08-31 Thread David Gwynne
On Tue, Aug 31, 2021 at 07:33:40AM +0200, Alexandr Nedvedicky wrote: > Hello, > > On Tue, Aug 31, 2021 at 02:40:57PM +1000, David Gwynne wrote: > > handling the "no" option with a token, and "yes" via a string made my > > eye twitch. > > &

better use the tokeniser in the pfctl parser

2021-08-30 Thread David Gwynne
handling the "no" option with a token, and "yes" via a string made my eye twitch. ok? or is the helpful yyerror a nice feature? Index: parse.y === RCS file: /cvs/src/sbin/pfctl/parse.y,v retrieving revision 1.709 diff -u -p -r1.709

Re: [External] : Re: if_etherbridge.c vs. parallel forwarding

2021-06-24 Thread David Gwynne
On Thu, Jun 24, 2021 at 09:31:20AM +0200, Alexandr Nedvedicky wrote: > Hello David, > > > > > > i think we can get away with not refcounting eb_entry structures at all. > > either they're in the etherbridge map/table or they're not, and the > > thing that takes them out of the map while holding

Re: if_etherbridge.c vs. parallel forwarding

2021-06-23 Thread David Gwynne
On Sat, Jun 19, 2021 at 12:32:04AM +0200, Alexandr Nedvedicky wrote: > Hello, > > skip reading if you are not interested in L2 switching combined > with bluhm's diff [1], which enables parallel forwarding. > > Hrvoje gave it a try and soon discovered some panics. Diff below > fixes a panic

Re: [External] : Re: parallel forwarding vs. bridges

2021-06-21 Thread David Gwynne
On Wed, Jun 16, 2021 at 02:59:19AM +0200, Alexandr Nedvedicky wrote: > Hello, > > > > > > as above, copyout with a sleeping lock is fine. > > > > the whole point of my change is to give us the ability to lock in the > > forwarding path separately to locking in the ioctl path. half of that is >

Re: ifnewlladdr spl

2021-06-15 Thread David Gwynne
> On 16 Jun 2021, at 00:39, Martin Pieuchot wrote: > > On 15/06/21(Tue) 22:52, David Gwynne wrote: >> On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote: >>> On 10/06/21(Thu) 19:17, Alexander Bluhm wrote: >> [...] >>>> The in6_ functi

Re: timecounting: refactor fraction-to-nanosecond, bintime-to-nanosecond conversions

2021-06-15 Thread David Gwynne
> On 16 Jun 2021, at 01:10, Scott Cheloha wrote: > > Hi, > > dlg@ just moved nsecuptime() and getnsecuptime() into kern_tc.c. > > To tidy it up I'd like to refactor the fraction-to-nanosecond and > bintime-to-nanosecond conversions into new functions so we only need > to write them once.

Re: [External] : rework pfsync deferral timeout handling

2021-06-15 Thread David Gwynne
> On 14 Jun 2021, at 19:12, Alexandr Nedvedicky > wrote: > > Hello, > > looks good to me. I think this should be committed > as-is. I have just one question, > > On Mon, Jun 14, 2021 at 01:58:06PM +1000, David Gwynne wrote: > >> @@ -1931,6 +1933,9

Re: ifnewlladdr spl

2021-06-15 Thread David Gwynne
On Mon, Jun 14, 2021 at 10:07:58AM +0200, Martin Pieuchot wrote: > On 10/06/21(Thu) 19:17, Alexander Bluhm wrote: > > Hi, > > > > I have seen this crash trace on a 6.6 based system, but I think the > > bug exists still in -current. It happened when an ixl(4) interface > > was removed from

Re: [External] : Re: parallel forwarding vs. bridges

2021-06-15 Thread David Gwynne
On Tue, Jun 08, 2021 at 06:54:25PM +0200, Alexandr Nedvedicky wrote: > Hello David, > > I'm still not sure if your change is ultimate fix, or just significantly > minimizes risk of the bug. If I understand things right, the problem we are > trying to solve: > DIOCGETSTATES we have in

rework pfsync deferral timeout handling

2021-06-13 Thread David Gwynne
pfsync deferrals are used so if you have firewalls that could both process packets, you defer sending the initial packet in state so the peer can learn about the state before potentially handling packets for it. there are three ways that a deferal can end. the preferred one is if a peer firewall

Re: [External] : Re: parallel forwarding vs. bridges

2021-06-13 Thread David Gwynne
On Sat, Jun 05, 2021 at 01:09:01PM +0200, Alexandr Nedvedicky wrote: > Hello David, > > > > > the scope of the pf locks likely needs reduction anyway. one of my > > I agree. pf_lock covers too much in PF currently. it protects, > all rules, tables and fragment caches. > > > production

(get)nsecuptime

2021-06-13 Thread David Gwynne
we have a few places that use a uint64_t with the number of nanosecons of uptime the machine has. this factors it out to make them a bit more generally available. i was going to add yet another one of these to pfsync, but thought it might be a good idea to factor them out first. ok? Index:

Re: [External] : Re: parallel forwarding vs. bridges

2021-06-03 Thread David Gwynne
On Thu, Jun 03, 2021 at 01:09:48AM +0200, Alexandr Nedvedicky wrote: > > pf_purge_expired_states(u_int32_t maxcheck) > > { > > > - cur = pf_state_ref(next); > > + do { > > + if ((cur->timeout == PFTM_UNLINKED) || > > + (pf_state_expires(cur) <= getuptime()))

Re: [External] : Re: parallel forwarding vs. bridges

2021-06-03 Thread David Gwynne
On Thu, Jun 03, 2021 at 01:09:48AM +0200, Alexandr Nedvedicky wrote: > Hello, > > looks like my earlier mail got eaten by SPAM filter, let's try again... > > > > > > moving pf locks to mutexes makes sense to me, but like you say, > > this will need testing and experimentation. one of the

Re: [External] : Re: parallel forwarding vs. bridges

2021-06-02 Thread David Gwynne
On Wed, May 19, 2021 at 01:48:26AM +0200, Alexandr Nedvedicky wrote: > Hello, > > just for the record... > > > > > > in current tree the ether_input() is protected by NET_LOCK(), which is > > > grabbed > > > by caller as a writer. bluhm's diff changes NET_LOCK() readlock, so > > >

let ipv4_check remember if the ip checksum was good

2021-06-01 Thread David Gwynne
if a bridge checked the ipv4 checksum and it was good, we can avoid checking it again in ip_input. ok? Index: ip_input.c === RCS file: /cvs/src/sys/netinet/ip_input.c,v retrieving revision 1.361 diff -u -p -r1.361 ip_input.c ---

Re: nvme(4): fix prpl sync length

2021-05-31 Thread David Gwynne
> On 1 Jun 2021, at 04:17, Patrick Wildt wrote: > > Hi, > > this call to sync the DMA mem wants to sync N - 1 number of prpl > entries, as the first segment is configured regularly, while the > addresses for the following segments (if more than 2), are in a > special DMA memory. > > The

Re: Enable pool cache on knote_pool

2021-05-31 Thread David Gwynne
> On 1 Jun 2021, at 02:58, Visa Hankala wrote: > > This patch enables the pool cache feature on the knote pool to reduce > the overhead of knote management. > > Profiling done by mpi@ and bluhm@ indicate that the potentially needless > allocation of knotes in kqueue_register() causes

Re: mcx(4): sync only received length on RX

2021-05-31 Thread David Gwynne
> On 1 Jun 2021, at 04:15, Patrick Wildt wrote: > > Hi, > > mcx(4) seems to sync the whole mapsize on processing a received packet. > As far as I know, we usually only sync the actual size that we have > received. Noticed this when doing bounce buffer tests, seeing that > it copied a lot

factor out ipv4 and ipv6 initial packet sanity checks for bridges

2021-05-30 Thread David Gwynne
if you're looking at an ip header, it makes sense to do some checks to make sure that the values and addresses make some sense. the canonical versions of these checks are in the ipv4 and ipv6 input paths, which makes sense. when bridge(4) is about to run packets through pf it makes sure the ip

Re: timeout_del_barrier(9): remove kernel lock

2021-05-10 Thread David Gwynne
On Thu, May 06, 2021 at 11:43:55AM -0500, Scott Cheloha wrote: > On Wed, May 05, 2021 at 11:05:06AM +1000, David Gwynne wrote: > > On Tue, May 04, 2021 at 11:54:31AM -0500, Scott Cheloha wrote: > > > > > > [...] > > > > > > Here is where I get

Re: timeout_del_barrier(9): remove kernel lock

2021-05-04 Thread David Gwynne
On Tue, May 04, 2021 at 11:54:31AM -0500, Scott Cheloha wrote: > On Tue, May 04, 2021 at 11:21:27PM +1000, David Gwynne wrote: > > On Tue, May 04, 2021 at 11:24:05AM +0200, Martin Pieuchot wrote: > > > On 04/05/21(Tue) 01:10, Scott Cheloha wrote: > > > > [...] &

Re: timeout_del_barrier(9): remove kernel lock

2021-05-04 Thread David Gwynne
On Tue, May 04, 2021 at 11:24:05AM +0200, Martin Pieuchot wrote: > On 04/05/21(Tue) 01:10, Scott Cheloha wrote: > > [...] > > I want to run softclock() without the kernel lock. The way to go, I > > think, is to first push the kernel lock down into timeout_run(), and > > then to remove the kernel

Re: have bpf kq events fire when the interface goes away

2021-04-21 Thread David Gwynne
On Wed, Apr 21, 2021 at 01:15:53PM +, Visa Hankala wrote: > On Wed, Apr 21, 2021 at 11:04:20AM +1000, David Gwynne wrote: > > On Wed, Apr 21, 2021 at 10:21:32AM +1000, David Gwynne wrote: > > > if you have a program that uses kq (or libevent) to wait for bytes to > > &g

Re: have bpf kq events fire when the interface goes away

2021-04-20 Thread David Gwynne
On Wed, Apr 21, 2021 at 10:21:32AM +1000, David Gwynne wrote: > if you have a program that uses kq (or libevent) to wait for bytes to > read off an idle network interface via /dev/bpf and that interface > goes away, the program doesnt get woken up. this is because the kq > read filter

have bpf kq events fire when the interface goes away

2021-04-20 Thread David Gwynne
if you have a program that uses kq (or libevent) to wait for bytes to read off an idle network interface via /dev/bpf and that interface goes away, the program doesnt get woken up. this is because the kq read filter in bpf only checks if there ares bytes available. because a detached interface

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

  1   2   3   4   5   6   7   8   9   10   >