> 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
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);
> > > +
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
> 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
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
> 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
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"
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
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
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
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
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
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
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
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)
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
> 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
> 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
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
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
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
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) {
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
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
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
> > ===
> >
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
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
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).
> > >
> &
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:
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
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
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
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
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:
> > > &
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
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
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
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
>
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
> > >
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
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.
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
>
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
>
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
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
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
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
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
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
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
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
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
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
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:
> > > >
> > > > >
> 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
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
> >
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
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
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.
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
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
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
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.
> >
&
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
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
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
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
>
> 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
> 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.
> 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
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
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
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
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
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:
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()))
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
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
> > >
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
---
> 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
> 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
> 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
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
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
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:
> > > > [...]
&
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
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
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
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
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
1 - 100 of 1023 matches
Mail list logo
