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? > My understanding is that it is also meant to be used for interface > output queues. So you could use this to prioritize ARP over IP > traffic if you wanted. (Well..you could anyway, but you don't > have as many options - many switches map the priorities 0-7 > onto 4 queues so there is only lower-priority than the default > 'prio=3'). > > > > Should it > > > really be part of "struct ifnet" ? > > > > > > > sthen@ pointed out that struct if_data was heavily used by our ports, and > > that such a change would require a version bump. Now, I may have overlooked > > a better place for it. > > I think it could go at the end of struct if_data without causing > trouble, though since it doesn't need to be exported to userland > isn't it better directly in ifnet rather than if_data? (if_data > is included in RTM_IFINFO's if_msghdr, whereas you need an ioctl > to see the non-if_data parts of struct ifnet from userland). "struct ifnet" would be better. > > 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?
