O, PROCUREMENT OF SUBSTITUTE GOODS
- * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
- * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
- * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
- * OUT OF THE USE OF THIS
this applies the use of tasks and a task_list to interface address
hooks. it's like the detach and linkstate hooks, except it seems other
things run the hooks more than things register hooks, and i can't tell
if the places that run the hooks have the NET_LOCK or not. not by casual
reading anyway.
On Wed, Nov 06, 2019 at 03:12:27PM +1000, David Gwynne wrote:
> this is a follow-up to "use tasks and a task_list to manage
> if_detachhooks" and converts the link state hooks to a task_list
> with pre-allocated tasks.
>
> it's mostly mechanical, except for carp. each
this is a follow-up to "use tasks and a task_list to manage
if_detachhooks" and converts the link state hooks to a task_list
with pre-allocated tasks.
it's mostly mechanical, except for carp. each carp interface has a link
state hook it registers on its parent, but each hook then runs against
this makes it harder to mess up the assignment of a protocol to the
right slot in the CTL_IPPROTO_NAMES initialiser. it also shrinks the
code a lot, and i think it makes what the array index means a lot more
explicit.
this gets used in sysctl(8), which still works as expected after
this change.
hook_establish can fail, but drivers are inconsistent about checking for
that. apparently there's also a requirement that detach hooks are
run in opposite order to the one they were established in, but that
is also applied inconsistently by drivers.
this replaces if_detachhooks with a task_list,
_ENTROPY) {
m->m_pkthdr.ph_flowid = M_FLOWID_VALID |
@@ -1203,10 +1170,9 @@ gre_input_key(struct mbuf **mp, int *off
#endif
(*input)(ifp, m);
- return (IPPROTO_DONE);
+ return (NULL);
decline:
- *mp = m;
- return (-1);
+ return (m);
(c) 2016 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
- * copyright notice and this permission notice appear in all copies.
- *
- * THE SOFTWARE IS PROVIDED
i disabled mobileip(4) with the idea that if noone complained, i'd
remove it. noone has complained, so im going to remove it.
starting at the edge, this removes the mobileip stuff from sysctl(8).
ok?
Index: sysctl.c
===
RCS file:
why? is it significantly faster? page allocation should be in the slow path.
dlg
> On 18 Oct 2019, at 08:33, Alexander Bluhm wrote:
>
> Hi,
>
> Can we replace the mutex that protects the mbuf allocation limit
> by an atomic operation?
>
> ok?
>
> bluhm
>
> Index: kern/uipc_mbuf.c
>
the ipv4 ones return void, and these can't fail, so make them return
nothing too.
ok?
Index: netinet/in_pcb.h
===
RCS file: /cvs/src/sys/netinet/in_pcb.h,v
retrieving revision 1.116
diff -u -p -r1.116 in_pcb.h
--- netinet/in_pcb.h
jca@ has already oked this. anyone else want to get on board?
Index: ip_ether.c
===
RCS file: ip_ether.c
diff -N ip_ether.c
--- ip_ether.c 10 Feb 2018 08:12:01 - 1.99
+++ /dev/null 1 Jan 1970 00:00:00 -
@@ -1,28 +0,0
so we can remove it, starting with taking it out of sys/conf/files.
ok?
Index: files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.674
diff -u -p -r1.674 files
--- files 29 Sep 2019 13:04:03 - 1.674
ok.
> On 2 Oct 2019, at 18:17, Claudio Jeker wrote:
>
> umb(4) is currently the only user of DLT_RAW. The problem with this is
> that it only works for IPv4 packets and that is less than ideal.
> This diff switches umb(4) to DLT_LOOP like lo(4), tun(4), gif(4), ...
>
> To make this work the
jmatthew@ and I thought I had broken trunk(4) because we could never get
it to come up on our new boxes, while aggr(4) always worked fine. It
turns out we were only ever testing it with new drivers like ixl(4) or
mcx(4), and we hadn't added code to them to properly report baudrate.
This tickled
On Mon, Sep 30, 2019 at 08:54:14AM +0200, Claudio Jeker wrote:
> On Mon, Sep 30, 2019 at 12:06:34PM +1000, David Gwynne wrote:
> > the "public" bpf api no longer supports custom copy functions, so we can
> > remove the plumbing for it internally in the bpf code.
> >
On Mon, Sep 30, 2019 at 06:49:14AM +0100, Jason McIntyre wrote:
> On Mon, Sep 30, 2019 at 10:28:50AM +1000, David Gwynne wrote:
> > i got an email recently asking how to configure the tunnel identifier
> > on an eoip(4) interface, and initially wanted to point the sender
>
the "public" bpf api no longer supports custom copy functions, so we can
remove the plumbing for it internally in the bpf code.
ok?
Index: bpf.c
===
RCS file: /cvs/src/sys/net/bpf.c,v
retrieving revision 1.180
diff -u -p -r1.180
i got an email recently asking how to configure the tunnel identifier
on an eoip(4) interface, and initially wanted to point the sender
at the manpage. unfortunately, the manpage is written for programmers
who have spent a lot of time in network drivers, ie, me. everyone
else who just wants to
this removes the cpfn argument from bpf_mtap_hdr since nothing uses it
anymore.
the last thing to use it was pflog, and that's been reworked to avoid it
a week or so ago. this is a largely mechanical diff to remove the cpfn
argument, and adjust all the callers to cope.
there's some followup work
radiotap code puts an mbuf on the stack so it can build a chain that
includes a radiotap header for bpf_mtap to chew on. bpf_mtap_hdr can do
that for you though.
bpf_mtap_hdr also cheats by using an m_hdr instead of a full mbuf,
which makes the stack usage less, but im arguing for the diff
kqueue stuff lets you provide some data when an event fires. generally
things that you read and write (ie, file descriptors) provide how much
data you can read or write. tun(4) provides how many packets you can
read, and how many bytes you could write.
im arguing that the number of packets is
this makes it easier to call at least.
it also brings it in line with bpf_tap_hdr. otherwise there's no
functional change.
ok?
Index: sys/net/bpf.c
===
RCS file: /cvs/src/sys/net/bpf.c,v
retrieving revision 1.177
diff -u -p -r1.177
tun_dev_write currently checks if the packet being written into the
kernel is less than the current if_mtu of the interface. we don't really
have a conflation of the mtu with the mru in any other driver, so i'd
like to remove it from tun(4).
we can also avoid a check at runtime about what type of
> On 5 Aug 2019, at 22:38, Alexander Bluhm wrote:
>
> On Thu, Jul 18, 2019 at 11:31:26PM +1000, David Gwynne wrote:
>>> And I have to do ifconfig vio0 down and ifconfig vio0 up to receive
>>> packets on the interface again.
>>
>> Can you look at sy
> On 30 Jul 2019, at 6:28 pm, Remi Locherer wrote:
>
> On Tue, Jul 30, 2019 at 01:36:59PM +1000, David Gwynne wrote:
>> a Two-Port MAC Relay is basically a cut down bridge(4). it only supports
>> two ports, and unconditionally relays packets between those ports
>>
On Tue, Jul 30, 2019 at 01:36:59PM +1000, David Gwynne wrote:
> a Two-Port MAC Relay is basically a cut down bridge(4). it only supports
> two ports, and unconditionally relays packets between those ports
> instead of doing learning or anything like that.
i had written a manpage too:
DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/*
+ * This code was written by David Gwynne as part
+ * of the Informati
this makes ifconfig output for a trunk/aggr look a bit smaller:
this is before the change:
aggr0: flags=8943 mtu 9000
lladdr bc:2c:55:9e:34:cb
index 7 priority 0 llprio 7
trunk: trunkproto lacp
trunk id: [(8000,bc:2c:55:9e:34:cb,0007,,),
this adds a couple of lines to the lacp output so you can see what
params are used on the wire. this can help if you've put switchports in
different port-channels or such. an example of that is:
aggr0: flags=8847 mtu 1500
lladdr fe:e1:ba:d0:35:21
index 10 priority 0 llprio 7
> On 18 Jul 2019, at 7:44 am, Alexander Bluhm wrote:
>
> On Tue, Jul 16, 2019 at 08:58:43PM -0300, Martin Pieuchot wrote:
>> On 16/07/19(Tue) 21:35, Alexander Bluhm wrote:
>>> Hi,
>>>
>>> When the kernel reaches the sysclt kern.maxclusters limit, operations
>>> get stuck while holding the
> On 17 Jul 2019, at 09:44, Martin Pieuchot wrote:
>
> On 15/07/19(Mon) 15:29, Todd C. Miller wrote:
>> On Mon, 15 Jul 2019 18:21:28 -0300, Martin Pieuchot wrote:
>>
>>> We have many home brewed ways to check Ethernet addresses. This diff
>>> introduces two macros similar to
this is not a request for oks, this is me backing up a hack i did to fix
a problem i needed a quick solution for.
we're in the process of moving a bunch of boxes to a new site, and are
lucky that we can take our address space with us. to let us gradually
migrate hosts i want to stretch the layer
and has the link "come up" when that one aggregation is selected
+ * by the LACP protocol.
+ */
+
+/*
+ * This code was written by David Gwynne as part
+ * of the Information Technology Infrastructure Group (ITIG) in the
+ * Faculty of Engineering, Architecture and Information Technology
+ * (EAIT).
+ */
interface rx queue processing includes detection of when the stack
becomes too busy to process packets.
there's three stages to this mechanism. firstly, everything is fine
and the packets are simply queued for processing. the second is the
"pressure_return" stage where the interface has queued a
this lets read and write the backpressure variables in the interface rx
queue (ifiq) handling:
dlg@ix ~$ sysctl net.link.ifrxq
net.link.ifrxq.pressure_return=6
net.link.ifrxq.pressure_drop=8
ideally this would be temporary, ie, id remove it from the tree once
everyone's happy with these numbers.
I'm mostly concerned that nothing that currently works breaks. This changes a
fairly fundamental chunk of code in the guts of the platform, so having
machines still work afterward would be nice.
Glad your T5220 works, hopefully the u45 will be ok too.
dlg
> On 20 Jun 2019, at 08:52, Kaashif
i backed this out before the 6.5 release because of bad interactions
with virtual interfaces like vlan and trunk. those should now be fixed,
so we can try the other backpressure mechanism again.
the summary is that we count the number of attempts to queue packets for
the system to process rather
to do it these days, but you should test that a trunk port
> cannot be attached to a bridge or carp or anything like this.
>
> You also forgot a comment that mentions the type as well.
>
> Reyk
>
>> Am 11.06.2019 um 08:33 schrieb David Gwynne :
>>
>> i think t
i think trunk(4) is the only thing left in the kernel that modifies an
interfaces if_type at runtime. this diff removes that fiddling, so
hopefully we can say that if_type is immutable after this.
however, while this diff reads well to me, i don't actually know if it
works. could someone kick the
this is a reposting of the diff i sent out a while back. it lets sparc64
enable iommu bypass, and then uses that bypass support for BUS_DMA_64BIT
dmamaps.
the main benefit is around performance. without this diff on an M4000,
tcpbench can do about 70Mbps before the system is CPU bound. all that
making tun(4) not IFT_TUNNEL and tap(4) not IFT_ETHER makes for some
interesting possibilities for fun with the rest of the kernel. I think
we should just not allow the if_types to be changed.
I have another diff somewhere to prevent changing the flags
(IFF_BROADCAST etc) somewhere too, but we
On Fri, Jun 07, 2019 at 07:36:36PM -0500, Scott Cheloha wrote:
> On Fri, Jun 07, 2019 at 02:34:20PM +1000, David Gwynne wrote:
> > nics are starting to offer the ability to timestamp packets when
> > they're received. other systems (eg linux and freebsd) have support
&g
> On 10 Jun 2019, at 03:14, Martin Pieuchot wrote:
>
> On 09/06/19(Sun) 18:41, Eygene Ryabinkin wrote:
>> Martin, good day.
>>
>> Sun, Jun 09, 2019 at 11:35:48AM -0300, Martin Pieuchot wrote:
>>> On 07/06/19(Fri) 20:55, Eygene Ryabinkin wrote:
With the hints from Martin Pieuchot had
currently mem bars and the rom address conflict lines in dmesg look
the same, which is a bit confusing. this makes rom conflicts lines say
"rom conflict" instead.
that looks like this:
dlg@r6415 pci$ dmesg | grep -A4 conflict
129:0:0: rom address conflict 0xfffc/0x4
129:0:1: rom address
te:
>>>
>>>
>>>
>>> Remi Locherer(remi.loche...@relo.ch) on 2019.05.15 23:15:03 +0200:
>>>> On Tue, Apr 30, 2019 at 11:10:37PM +0200, Remi Locherer wrote:
>>>>> On Mon, Apr 29, 2019 at 11:10:31AM +0100, Stuart Henderson wrote:
>>>&
nics are starting to offer the ability to timestamp packets when
they're received. other systems (eg linux and freebsd) have support
for recording that timestamp on mbufs and then using it as the
backend for at least the SO_TIMESTAMP socket option instead of a
call to microtime().
this implements
-T erspan lets you force parsing a GRE packet as ERSPAN
Devices supportin ERSPAN type I allow arbitrary GRE protocol numbers to
be specified for encapsulating the spanned Ethernet packets. This lets
tcpdump cope with that by letting the user force erspan packet
processing.
This follows the
i originally came at this from the other side, where i wanted to run
kqueue_enqueue and _dequeue without the KERNEL_LOCK, but that implied
making kqueue_scan use the mutex too, which allowed the syscall to
become less locked.
it assumes that the existing locking in kqueue_scan is in the right
Nice work
On Tue., 30 Apr. 2019, 22:27 Claudio Jeker, wrote:
> We have released OpenBGPD 6.5p0, which will be arriving in the
> OpenBGPD directory of your local OpenBSD mirror soon.
>
> OpenBGPD is a free, functional, and secure implementation of the
> Border Gateway Protocol (BGP-4). It is a
> On 29 Apr 2019, at 4:59 pm, Remi Locherer wrote:
>
> Hi David
>
> On Mon, Apr 29, 2019 at 11:53:27AM +1000, David Gwynne wrote:
>> it's always bothered me that i config areas on a crisco using a number,
>> but then have to think hard to convert that n
it's always bothered me that i config areas on a crisco using a number,
but then have to think hard to convert that number to an address for use
in openbsd. eg, i was given area 700 in one place, which is 0.0.2.188
as an address. super annoying.
so this changes the ospfd parser so it accepts both
nothing else in the kernel needs to look inside struct ifvlan.
so this diff moves it. the next step will be renaming ifvlan to
vlan_softc so it is like all the other drivers in the tree, and
referring to it as "sc" instead of "ifv" as a variable. but this is a
first step.
ok?
Index: if_vlan.c
> On 22 Apr 2019, at 5:45 am, Martin Pieuchot wrote:
>
> Diff below removes the KERNEL_LOCK() from bridge(4)'s output fast-path.
>
> To do so, it redefines the ifp <-> bridge relationship. Currently every
> interface in a bridge(4) contains a pointer to that bridge's port. This
>
i want to remove the mobileip driver. disabling it is a good start.
it would be generous to say that mobileip is a very niche protocol. it
is not great on the wire, it cannot encap anything except ipv4, and it
lacks widespread support in other operating systems. the other bsds
appear to support
> On 15 Apr 2019, at 05:56, Klemens Nanni wrote:
>
> On Sun, Apr 14, 2019 at 07:46:59PM +0200, Sebastian Benoit wrote:
>> I dont mind keeping vlan/vlandev either, but then they should be aliases,
>> not with their own function.
> Fine with me as well.
>
> Diff below removes the old functions
ive been working on RFC 2983 support, with extended functionality.
rfc 2983 is "Differentiated Services and Tunnels", and discusses where
prio values should go and come from on tunnel ingress and egress. we
currentl support setting the packet on tunnel ingress using the txprio
functionliaty. this
this is another go at implementing tx mitigation.
it is mostly the same as the previous attempts in that actual tx
is deferred to a network taskq unless a backlog of packets is
reached. when the task or the backlog is reached the actual hardware
transmit routine is called. this is all hidden
the mpls exp bits are now defined as a prio field, but we don't have
support for that currently.
this lets the mpls tunnelling interfaces configure the use of the exp
fields for prio with the same machinery used for all the other tunnel
interfaces. the interfaces default to using 0 for the value
seeing the key-id in particular helped me debug a problem here.
ok?
Index: ospf.h
===
RCS file: /cvs/src/usr.sbin/tcpdump/ospf.h,v
retrieving revision 1.10
diff -u -p -r1.10 ospf.h
--- ospf.h 4 Aug 2010 16:47:01 -
Temperature Low Warning Flag = False
SFP+ 6 Voltage Low Warning Flag = False
SFP+ 6 Tx Bias Low Warning Flag = False
SFP+ 6 Tx Power Low Warning Flag= False
SFP+ 6 Rx Power Low Warning Flag= False
10GBASE-SR
On Mon, Apr 08, 2019 at 02:21:36PM +1000, David Gwynne
OLWORD;
+}
+
+intif_sff_info(int, const char *, int);
+
+void
+transceiver(const char *value, int d)
+{
+ if (if_sff_info(s, name, 0) == -1)
+ err(1, "%s %s", name, __func__);
+}
+
+void
+transceiverdump(const char *value, int d)
+{
+ if (if_sff_info(s, name, 1)
ok?
Index: interface.h
===
RCS file: /cvs/src/usr.sbin/tcpdump/interface.h,v
retrieving revision 1.79
diff -u -p -r1.79 interface.h
--- interface.h 22 Oct 2018 16:12:45 - 1.79
+++ interface.h 4 Apr 2019 01:54:37 -
@@
nothing uses it anymore, and i don't think it's useful either.
for those who don't know what it did, it marked the threads used by a
taskq so the scheduler knew they shouldnt sleep. this was used in the
early stages of the mpsafe network stack changes to mark the softnet
taskqs as nonsleeping so
ok?
Index: GENERIC
===
RCS file: /cvs/src/sys/conf/GENERIC,v
retrieving revision 1.257
diff -u -p -r1.257 GENERIC
--- GENERIC 20 Dec 2018 23:00:55 - 1.257
+++ GENERIC 18 Mar 2019 03:22:03 -
@@ -94,6 +94,7 @@
> On 15 Mar 2019, at 16:37, Otto Moerbeek wrote:
>
> On Fri, Mar 15, 2019 at 04:15:55PM +1000, David Gwynne wrote:
>
>>
>>
>>> On 14 Mar 2019, at 19:36, Otto Moerbeek wrote:
>>>
>>> Hi,
>>>
>>> So i have a little IP
> On 14 Mar 2019, at 19:36, Otto Moerbeek wrote:
>
> Hi,
>
> So i have a little IPv6 problem.
>
> I have a machine in colocation that has IPv6. I have my home cable
> modem connection that does not have it.
>
> So I thought: I make my own tunnel. First I tried gif(4), that worked,
> but
On Tue, Mar 05, 2019 at 12:03:05PM +1000, David Gwynne wrote:
> this extends the fildrop mechanism so you can drop the packets with bpf
> using the existing fildrop method, but with an extra tweak so you can
> avoid the cost of copying packets to userland.
>
> i wanted to qu
this extends the fildrop mechanism so you can drop the packets with bpf
using the existing fildrop method, but with an extra tweak so you can
avoid the cost of copying packets to userland.
i wanted to quickly drop some packets in the rx interrupt path to try
and prioritise some traffic getting
ok.
> On 5 Mar 2019, at 02:46, Denis Fondras wrote:
>
> Simple diff to allow IPv6 through pppx(4).
>
> Denis
>
> Index: net/if_pppx.c
> ===
> RCS file: /cvs/src/sys/net/if_pppx.c,v
> retrieving revision 1.66
> diff -u -p -r1.66
this combines errors and qdrops into fails, and shows them by default.
if you want to look at drops or errors, you can use d or f to switch to
that view.
this also changes netstat so it shows fails by default which is a
combination of errors and qdrops too, but -d and -e force drops or
errors
lint thinks uvm_swap_get() looks like a function name, so this uses .Fn
to mark it up as one.
ok?
Index: systat.1
===
RCS file: /cvs/src/usr.bin/systat/systat.1,v
retrieving revision 1.110
diff -u -p -r1.110 systat.1
--- systat.1
using ifiq_input lets ix check the return value from that function
so it can call if_rxr_livelocked as needed. calling if_rxr_livelocked
will make it shrinkthe rx rings before ifiq_input has to start
dropping packets. the idea being that dropping in hardware lets the
cpu spend more time
it is in fact harmful for the stack to block hardware interrupts.
the nettq can run on cpu0, which is where interrupts for nics come in
too. if a busy nic has fed the stack a lot of work, and the stack is on
cpu0, then the stack will stop the driver pulling packets off the nic
again. the hardware
this changes how ifiq_input measure whether there is too much work for
the network stack to do, which in turn is used to decide whether it
should drop packets or not.
currently we count the number of packets still on the queue, and we drop
when that backlog of packets gets too high. currently
,706 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2015 Rafael Zalamena
+ * Copyright (c) 2019 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
+ * copyright notice and this permis
On Mon, Feb 25, 2019 at 08:44:35AM +0100, Claudio Jeker wrote:
> On Mon, Feb 25, 2019 at 10:49:16AM +1000, David Gwynne wrote:
> > the mcl2k2 pool, aka the intel mbuf cluster pool, gets set up to allocate
> > at least 2048 + 2 bytes, which gets rounded up by 64 bytes to 2112
>
On Mon, Feb 25, 2019 at 03:28:58PM +1000, David Gwynne wrote:
> On Mon, Feb 25, 2019 at 10:37:40AM +1000, David Gwynne wrote:
> >
> >
> > > On 22 Feb 2019, at 05:01, Martin Pieuchot wrote:
> > >
> > > On 21/02/19(Thu) 07:35, David Gwynne wrote:
&
On Mon, Feb 25, 2019 at 10:37:40AM +1000, David Gwynne wrote:
>
>
> > On 22 Feb 2019, at 05:01, Martin Pieuchot wrote:
> >
> > On 21/02/19(Thu) 07:35, David Gwynne wrote:
> >>> On 20 Feb 2019, at 11:21 pm, Martin Pieuchot wrote:
> >>>
i had to think a bit about what rw_lock returns, so i made this.
is this worth it?
Index: rwlock.9
===
RCS file: /cvs/src/share/man/man9/rwlock.9,v
retrieving revision 1.23
diff -u -p -r1.23 rwlock.9
--- rwlock.94 Jun 2018
the mcl2k2 pool, aka the intel mbuf cluster pool, gets set up to allocate
at least 2048 + 2 bytes, which gets rounded up by 64 bytes to 2112
bytes. this diff makes ix move the reception of packets to the end of
the 2112 byte allocation so there's space left at the front of the mbuf.
this in turn
> On 22 Feb 2019, at 05:01, Martin Pieuchot wrote:
>
> On 21/02/19(Thu) 07:35, David Gwynne wrote:
>>> On 20 Feb 2019, at 11:21 pm, Martin Pieuchot wrote:
>>>
>>> On 20/02/19(Wed) 14:44, David Gw
On Fri, Feb 22, 2019 at 09:56:58AM -0300, Martin Pieuchot wrote:
> On 22/02/19(Fri) 15:01, David Gwynne wrote:
> > On Thu, Feb 21, 2019 at 04:29:27PM -0300, Martin Pieuchot wrote:
> > > On 21/02/19(Thu) 14:19, David Gwynne wrote:
> > > > right now we add vlan_inp
1970 00:00:00 -
+++ pci_mapreg_map.922 Feb 2019 06:32:12 -
@@ -0,0 +1,151 @@
+.\"$OpenBSD$
+.\"
+.\" Copyright (c) 2019 David Gwynne
+.\" All rights reserved.
+.\"
+.\" Permission to use, copy, modify, and distribute this software for any
+.\" pu
On Thu, Feb 21, 2019 at 04:29:27PM -0300, Martin Pieuchot wrote:
> On 21/02/19(Thu) 14:19, David Gwynne wrote:
> > right now we add vlan_input as a possible input handler on the parent
> > interface, and if the packet is for a vlan we take it and pretend we
> > received it
right now we add vlan_input as a possible input handler on the parent
interface, and if the packet is for a vlan we take it and pretend we
received it on the vlan interface by calling if_input against that mbuf.
as mpi notes, the if input queue stuff looks like a lot of work,
especially for a
> On 20 Feb 2019, at 11:21 pm, Martin Pieuchot wrote:
>
> On 20/02/19(Wed) 14:44, David Gwynne wrote:
>> Index: sys/net/if.c
>> ===
>> RCS file: /cvs/src/sys/net/if.c,v
>> retrieving revision
jsg@ pointed out that stsp sniped the ioctl numbers i was using.
this diff moves them into 220-212.
On Wed, Feb 20, 2019 at 01:33:00PM +1000, David Gwynne wrote:
> This splits up the mpw config ioctl so the same functionality is
> implemented in a bunch of smaller and more specific
This splits up the mpw config ioctl so the same functionality is
implemented in a bunch of smaller and more specific ioctls. This
simplifies configuration of an interface cos you can incrementally
configure it instead of having to line up all the bits correctly for the
jumbo ioctl.
It also allows
mpi's recent post about vlan performance which happened to use ix
reminded me that i had some diffz for ix that may be relevant to
the discussion.
this uses the loads and stores of the produce and consumer indexes
to calculate free space in the start path and for figuring out how
much space to
yes!
ok by me.
> On 14 Feb 2019, at 00:02, Martin Pieuchot wrote:
>
> Now that mpw(4) is an Ethernet interface, can I get rid of the following
> hacks?
>
> Index: net/if_bridge.c
> ===
> RCS file: /cvs/src/sys/net/if_bridge.c,v
>
this makes it easier to call sbcreatecontrol without requiring casts.
it makes the argument const as well, and promotes the length variable to
size_t.
ok?
Index: sys/socketvar.h
===
RCS file: /cvs/src/sys/sys/socketvar.h,v
> On 4 Feb 2019, at 22:00, Tim Kuijsten wrote:
>
> On Mon, Feb 04, 2019 at 12:07:22PM +1000, David Gwynne wrote:
>> Currently you can change a tun interface from being point to point to
>> being a broadcast interface. Why?
>
> I'm using broadcast mode in my o
Currently you can change a tun interface from being point to point to
being a broadcast interface. Why?
This cuts out the ability to change it. Note that the ioctl code is
shared by tap, so it still has IFF_BROADCAST code that gets run, you
should just not be able to change the flags, only read
this has reads from tun load the AF out of the data rather than point to
it, then has the switch statement compare to the swapped AF values.
ok?
Index: if_tun.c
===
RCS file: /cvs/src/sys/net/if_tun.c,v
retrieving revision 1.184
On Fri, Feb 01, 2019 at 02:40:17PM -0200, Martin Pieuchot wrote:
> On 31/01/19(Thu) 13:31, David Gwynne wrote:
> > On Wed, Jan 30, 2019 at 11:54:45AM -0200, Martin Pieuchot wrote:
> > > On 30/01/19(Wed) 11:48, David Gwynne wrote:
> > > > mpls uses AF_MPLS routes with
On Wed, Jan 30, 2019 at 11:54:45AM -0200, Martin Pieuchot wrote:
> On 30/01/19(Wed) 11:48, David Gwynne wrote:
> > mpls uses AF_MPLS routes with RTF_LOCAL set on them to know which tags
> > are used as input for the mpe and mpw interfaces. setting this up
> > currently go
I mean rdomain 0 below, not 1.
> On 30 Jan 2019, at 11:48, David Gwynne wrote:
>
> mpls uses AF_MPLS routes with RTF_LOCAL set on them to know which tags
> are used as input for the mpe and mpw interfaces. setting this up
> currently goes through rt_ifa_add, but that has a cou
mpls uses AF_MPLS routes with RTF_LOCAL set on them to know which tags
are used as input for the mpe and mpw interfaces. setting this up
currently goes through rt_ifa_add, but that has a couple of features
that are undesirable for mpls.
Firstly, rt_ifa_add unconditionally sets RTF_MPATH on the
> On 27 Dec 2018, at 5:42 pm, Claudio Jeker wrote:
>
> On Wed, Dec 26, 2018 at 09:27:59PM +0100, Denis Fondras wrote:
>> Resend because of nasty typo :/
>>
>> On Mon, Dec 24, 2018 at 08:43:10PM -0200, Martin Pieuchot wrote:
>>> I'm not happy with adding the IFF_MULTICAST flag and
301 - 400 of 1094 matches
Mail list logo
