Re: Simplify bridge(4)

2016-03-29 Thread Ryota Ozaki
On Tue, Mar 29, 2016 at 12:27 AM, Taylor R Campbell wrote: >Date: Mon, 28 Mar 2016 16:07:19 +0900 >From: Ryota Ozaki > >On Fri, Mar 25, 2016 at 11:40 PM, Taylor R Campbell > wrote:

Re: Simplify bridge(4)

2016-03-28 Thread Taylor R Campbell
Date: Mon, 28 Mar 2016 16:07:19 +0900 From: Ryota Ozaki On Fri, Mar 25, 2016 at 11:40 PM, Taylor R Campbell wrote: > No need for the _PSZ variants here: the bridge list is used only under > an exclusive lock. >

Re: Simplify bridge(4)

2016-03-28 Thread Ryota Ozaki
On Fri, Mar 25, 2016 at 11:40 PM, Taylor R Campbell wrote: >Date: Wed, 23 Mar 2016 20:03:54 +0900 >From: Ryota Ozaki > >...not so much soon though, I prepared patches: >

Re: Simplify bridge(4)

2016-03-25 Thread Taylor R Campbell
Date: Wed, 23 Mar 2016 20:03:54 +0900 From: Ryota Ozaki ...not so much soon though, I prepared patches: http://www.netbsd.org/~ozaki-r/bridge-psz-list.diff http://www.netbsd.org/~ozaki-r/bridge-default-mpsafe.diff The first one introduces membar to

Re: Simplify bridge(4)

2016-03-23 Thread Ryota Ozaki
> >> >> Thanks to introducing softint-based if_input, >>we can simplify bridge(4). >> >> Awesome! I love patches that have loads more -'s than +'s, and >> simplify locking schemes, and remove sketchy cpu_intr_p conditionals, >> and things like that. >&

Re: Simplify bridge(4)

2016-02-16 Thread Pierre Pronchery
On 02/16/16 14:26, David Brownlee wrote: > a) Single interface machine running xen which needs the xen VMs on an > internal network with dhcp and VPN/NAT on the external interface (this > becomes quickly brain twisting and the solution is to plug in an > additional ethernet card, just to act as

Re: Simplify bridge(4)

2016-02-16 Thread David Brownlee
On 15 February 2016 at 04:01, Ryota Ozaki wrote: > On Sat, Feb 13, 2016 at 7:19 AM, Mouse wrote: >> Sounds to me as though the most sensible way to model that would be to >> give the address to the bridge interface itself. >> >> I don't think I've

Re: Simplify bridge(4)

2016-02-14 Thread Ryota Ozaki
On Sat, Feb 13, 2016 at 7:19 AM, Mouse wrote: >> tap(4) is a direct interface between userland and the network. > > Well, where "the network" refers to the Ethernet stack and higher > layers within the kernel, not to any real networking medium. > >> vether(4) would not

Re: Simplify bridge(4)

2016-02-13 Thread Rhialto
On Fri 12 Feb 2016 at 10:17:31 -0800, John Nemeth wrote: > tap(4) is a direct interface between userland and the network. > vether(4) would not be (although you could use BPF, etc.). It > would be an ethernet device that represents the host. If you know > how to configure Cisco devices,

Re: Simplify bridge(4)

2016-02-13 Thread Mouse
>> tap(4) is a direct interface between userland and the network. >> vether(4) would not be (although you could use BPF, etc.). [...] > As someone who tinkers with virtual machine emulators (PDP-10, PDP-11 > etc) I like tap(4) very much, [...]. It would be REALLY inconvenient > if suddenly

Re: Simplify bridge(4)

2016-02-13 Thread Rhialto
On Fri 12 Feb 2016 at 17:19:59 -0500, Mouse wrote: > Indeed, > I would say that bridge should not, conceptually, be a network > interface at all; I suspect it was done as a network interface simply > because that got a lot of infrastructure for free - and, if it works to > put an address on the

Re: Simplify bridge(4)

2016-02-13 Thread Mouse
> Linux takes it even further. If you add an interface to a bridge, the > interface can't be an IP endpoint any more. You have to use the > bridge for that instead. I agree that is stupid. I would advocate against doing it if anyone were to propose it here. /~\ The ASCII

vether vs tap [was Re: Simplify bridge(4)]

2016-02-13 Thread Taylor R Campbell
Date: Fri, 12 Feb 2016 21:21:29 -0500 From: Thor Lancelot Simon On Fri, Feb 12, 2016 at 10:17:31AM -0800, John Nemeth wrote: > tap(4) is a direct interface between userland and the network. Only if you actually hook something up to the userland side.

Re: Simplify bridge(4)

2016-02-12 Thread Roy Marples
On 12/02/2016 08:34, Ryota Ozaki wrote: > On Thu, Feb 11, 2016 at 3:17 AM, Mouse wrote: >>> [J]ust wondering if we are going to see vether(4) anytime soon. >> >> How would this vether differ from the existing tap? Presumably I'm >> just missing something > >

Re: Simplify bridge(4)

2016-02-12 Thread Ryota Ozaki
2016/02/11 2:36 "Taylor R Campbell" <campbell+netbsd-tech-k...@mumble.net>: > >Date: Wed, 10 Feb 2016 18:56:46 +0900 >From: Ryota Ozaki <ozak...@netbsd.org> > >Thanks to introducing softint-based if_input, >we can simplify bridge(4). >

Re: Simplify bridge(4)

2016-02-12 Thread Ryota Ozaki
On Thu, Feb 11, 2016 at 3:17 AM, Mouse wrote: >> [J]ust wondering if we are going to see vether(4) anytime soon. > > How would this vether differ from the existing tap? Presumably I'm > just missing something dhcpcd didn't work well with bridge(4) and tap(4)

Re: Simplify bridge(4)

2016-02-12 Thread Robert Swindells
Ryota Ozaki wrote: >On Thu, Feb 11, 2016 at 3:17 AM, Mouse wrote: >>> [J]ust wondering if we are going to see vether(4) anytime soon. >> >> How would this vether differ from the existing tap? Presumably I'm >> just missing something > >dhcpcd didn't work well

Re: Simplify bridge(4)

2016-02-12 Thread John Nemeth
On Feb 12, 10:33am, Roy Marples wrote: } On 12/02/2016 08:34, Ryota Ozaki wrote: } > On Thu, Feb 11, 2016 at 3:17 AM, Mouse wrote: } >>> [J]ust wondering if we are going to see vether(4) anytime soon. } >> } >> How would this vether differ from the existing tap?

Re: Simplify bridge(4)

2016-02-12 Thread Mouse
> tap(4) is a direct interface between userland and the network. Well, where "the network" refers to the Ethernet stack and higher layers within the kernel, not to any real networking medium. > vether(4) would not be (although you could use BPF, etc.). It would > be an ethernet device that

Re: Simplify bridge(4)

2016-02-12 Thread Thor Lancelot Simon
On Fri, Feb 12, 2016 at 10:17:31AM -0800, John Nemeth wrote: > On Feb 12, 10:33am, Roy Marples wrote: > } On 12/02/2016 08:34, Ryota Ozaki wrote: > } > On Thu, Feb 11, 2016 at 3:17 AM, Mouse wrote: > } >>> [J]ust wondering if we are going to see vether(4) anytime soon.

Re: Simplify bridge(4)

2016-02-10 Thread Taylor R Campbell
Date: Wed, 10 Feb 2016 18:56:46 +0900 From: Ryota Ozaki <ozak...@netbsd.org> Thanks to introducing softint-based if_input, we can simplify bridge(4). Awesome! I love patches that have loads more -'s than +'s, and simplify locking schemes, and remove sketchy cpu_intr_p condit

Re: Simplify bridge(4)

2016-02-10 Thread John Nemeth
On Feb 10, 6:56pm, Ryota Ozaki wrote: } } Thanks to introducing softint-based if_input, } we can simplify bridge(4). } } - Remove spin mutexes } - They were needed because some code of bridge could run in } hardware interrupt context } - We now need only an adaptive mutex for each

Re: Simplify bridge(4)

2016-02-10 Thread Mouse
> [J]ust wondering if we are going to see vether(4) anytime soon. How would this vether differ from the existing tap? Presumably I'm just missing something > This would simplify the administration and possibly the code of > bridge(4) in that bridge(4) would become strictly transit and not >

Simplify bridge(4)

2016-02-10 Thread Ryota Ozaki
Hi, Thanks to introducing softint-based if_input, we can simplify bridge(4). - Remove spin mutexes - They were needed because some code of bridge could run in hardware interrupt context - We now need only an adaptive mutex for each shared object (a member list and a forwarding table