Re: ifconfig: remove obsolete vlan code

> 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

Re: [PATCH]: Make -P option of mount_mfs(8) support DUIDs

On Mon, Apr 08, 2019 at 12:35:41AM +0100, Rafael Neves wrote: > Hi tech@, > > When I had to change a HD between machines I figured out that -P option > of mount_mfs(8) does not work with DUIDs: > > # mount_mfs -P ca7552589896b01e.d swap /mnt > mount_mfs: cannot stat ca7552589896b01e.d: No such

Re: ifconfig: remove obsolete vlan code

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 while keeping `[-]vlan' and `[-]vlandev' as aliases for

jme(4): jme_start() use JME_MAXTXSEGS when checking available TX descs

jme_start() should be checking if JME_MAXTXSEGS TX descs are available instead of just the 1 reserved descriptor (JME_TXD_RSVD). Index: if_jme.c === RCS file: /home/cvs/src/sys/dev/pci/if_jme.c,v retrieving revision 1.51 diff -u -p

Re: ifconfig: remove obsolete vlan code

Stuart Henderson(s...@spacehopper.org) on 2019.04.14 11:35:57 +0100: > I still don't understand why we wouldn't just keep these as aliases to > parent/vnetid.. When parent/vnetid was introduced, the idea was to remove the old ones. Usually we clean things up eventually, otherwise in a year or

Re: ifconfig: remove obsolete vlan code

I still don't understand why we wouldn't just keep these as aliases to parent/vnetid.. On 13 April 2019 19:41:33 Klemens Nanni wrote: `vlan' and `[-]vlandev' were deprecated starting with 6.3, 6.5 printed a warning when using it and current.html had a note as well, now is the time to remove

Re: let mpe/mpw/mpip use exp as a txprio field

I say great. On Sun, Apr 14, 2019, 12:00 AM David Gwynne wrote: > 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

tunnel interface rxprio config

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

tx mitigation again

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

let mpe/mpw/mpip use exp as a txprio field

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