Add support for register shift/io-width to com(4)

A popular choice for adding serial ports (UARTs) to SoCs is to copy and paste some Syopsys Designware "IP" into the design. These ports are almost, but not quite, compatible with the NS16550. The main difference is that this "IP" can be synthesized with different register widths and layouts to

Re: [PATCH] Update default QoS markers for ssh

On 2018/04/01 13:29, Job Snijders wrote: > On Sun, Apr 01, 2018 at 11:29:55AM +0100, Stuart Henderson wrote: > > On 2018/03/31 16:10, Job Snijders wrote: > > > TL;DR: I propose to update the defaults to use DSCP "AF21" (Low > > > Latency Data) for interactive session traffic, and CS1 ("Lower > > >

Re: route(8): improve show output

On Sun, Apr 01, 2018 at 11:09:18AM +0200, Florian Obser wrote: > On Sun, Apr 01, 2018 at 10:42:09AM +0200, Otto Moerbeek wrote: > > On Sun, Apr 01, 2018 at 10:39:39AM +0200, Florian Obser wrote: > > > > > On a backbone router with many interfaces route show scrolls for quite > > > some time and

Re: [PATCH] Update default QoS markers for ssh

On Sun, Apr 01, 2018 at 11:29:55AM +0100, Stuart Henderson wrote: > On 2018/03/31 16:10, Job Snijders wrote: > > TL;DR: I propose to update the defaults to use DSCP "AF21" (Low > > Latency Data) for interactive session traffic, and CS1 ("Lower > > Effort") for non-interactive traffic. This applies

Re: pf generic packet delay

* Martin Pieuchot [2018-02-23 10:04]: > On 23/02/18(Fri) 04:08, Henning Brauer wrote: > > * Martin Pieuchot [2018-02-21 09:37]: > > > On 21/02/18(Wed) 02:37, Henning Brauer wrote: > > > I'd suggest moving the pool allocation and the function in net/pf*.c > > >

Re: [PATCH] Update default QoS markers for ssh

> I think this is the right thing to do, but needs handling in conjunction > with changes to PF, which has dual queue-setting (IPTOS_LOWDELAY packets pf has to change first?? I don't understand the requirement that pf must be capable of handling this naunce of packets, before any of our

Re: route(8): improve show output

On Sun, Apr 01, 2018 at 10:42:09AM +0200, Otto Moerbeek wrote: > On Sun, Apr 01, 2018 at 10:39:39AM +0200, Florian Obser wrote: > > > On a backbone router with many interfaces route show scrolls for quite > > some time and it is difficult to see at a glance what is going on. > > > > Colour

Re: [PATCH] Update default QoS markers for ssh

On 2018/03/31 16:10, Job Snijders wrote: > TL;DR: I propose to update the defaults to use DSCP "AF21" (Low Latency > Data) for interactive session traffic, and CS1 ("Lower Effort") for > non-interactive traffic. This applies to both IPv4 and IPv6. I think this is the right thing to do, but needs

Re: route(8): improve show output

On Sun, Apr 01, 2018 at 10:39:39AM +0200, Florian Obser wrote: > On a backbone router with many interfaces route show scrolls for quite > some time and it is difficult to see at a glance what is going on. > > Colour coding is an obvious improvement. > > The following diff sets the background

route(8): improve show output

On a backbone router with many interfaces route show scrolls for quite some time and it is difficult to see at a glance what is going on. Colour coding is an obvious improvement. The following diff sets the background colour to green for up routes and black for down routes. The default route

Re: dd(1): snprintf+writev -> dprintf

On Sat, Mar 31, 2018 at 01:41:00PM -0600, Theo de Raadt wrote: > > On Sat, Mar 31, 2018 at 01:04:43PM -0600, Theo de Raadt wrote: > > > The only worry about converting from iov to dprintf could be some > > > atomicity requirement. I don't really see that in play here, I think > > > the iov uses

Re: interface queue transmit mitigation (again)

On 28.3.2018. 11:42, Hrvoje Popovski wrote: > Hi all, > > with this diff i'm getting 1.43Mpps on > 12 x Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz, 2400.01 MHz > > with plain kernel i'm getting 1.12Mpps and with older diff's i was > getting 1.31Mpps ... On box with 6 x Intel(R) Xeon(R) CPU

Re: [PATCH] Update default QoS markers for ssh

On 2018/04/01 08:59, Theo de Raadt wrote: > > I think this is the right thing to do, but needs handling in conjunction > > with changes to PF, which has dual queue-setting (IPTOS_LOWDELAY packets > > pf has to change first?? > > I don't understand the requirement that pf must be capable of