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:
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
> 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
> 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
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
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
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
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
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
> 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
> 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
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
>
> 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
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
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,
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
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
> 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++
> 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
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
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->
> 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
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
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.
> > >
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,
>
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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 +
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
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
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.
> > >
> >
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
> 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:
>>
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,
> >
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
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 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
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
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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
> 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
>
> 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
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().
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
> 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
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
> 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
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
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
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
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
> 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
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
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
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,
>
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
. 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.
> >>>>>
> >
> 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
> 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
> 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
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
> 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
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 - 100 of 934 matches
Mail list logo
