On Wed, 8 Jun 2016 15:12:23 +0200 Martin Pieuchot <m...@openbsd.org> wrote:
> On 07/06/16(Tue) 22:02, Stuart Henderson wrote: > > On 2016/06/07 21:49, Vincent Gross wrote: > > > > > > It's how henning@ set things up when integrating the new queuing > > > mechanism. > > > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/uipc_mbuf.c#rev1.160 > > > > > > > Is there any use for this apart for vlan(4) interfaces? > > > > > > AFAICT, no. > > In this case I'd suggest to make this a vlan(4) specific > configuration, is there a problem with that? Actually, there is. Consider this setup: # ifconfig vlan4 vlan 4 vlandev em0 up # ifconfig vlan5 vlan 4 vlandev em1 up # ifconfig trunk0 trunkproto failover trunkport vlan4 trunport vlan5 up # ifconfig trunk0 10.10.10.50/24 llprio in vlan4 or vlan5 is useless because they are not initiating ARP requests, and adding lookups in trunk would be the Wrong Way. This particular exemple might seem far-fetched, but I'm sure there are plenty worse actually deployed. [...] > > > I don't think we should make a special case for vlan(4), this > > > kind of detail do not belong to the arp(4) or bpf(4) layer. > > Which kind detail are you talking about? I still don't understand how > the scope if this problem is beyond vlan(4). Are you also interested > in queue priority? > What I meant is arp(4) and bpf(4) and maybe other protocols should not need to concern themselves about the nature of the device they are transmitting on. This problem manifests itself only on vlan(4) so far, because of the CoS field in the 802.1Q header. But the problem is broader than that actually, as some network protocols completely bypass pf(4), and it can have consequences as we go down into the network device stacking.
