On 2020-11-27 18:27, Jakub Kicinski wrote: > On Thu, 26 Nov 2020 21:00:46 +0100 Thomas Karlsson wrote: >> On 2020-11-26 00:01, Jakub Kicinski wrote: >>> On Wed, 25 Nov 2020 23:15:39 +0100 Thomas Karlsson wrote: >>>> Or is there a way to set the parameters in a more "raw" form that >>>> does not require a patch to iproute2 with parameter parsing, error >>>> handing, man pages updates, etc. I feel that I'm getting in over my >>>> head here. >>> >>> We're here to assist! Netlink takes a little bit of effort >>> to comprehend but it's very simple once you get the mechanics! >>> >> >> Thanks for the encouragement, I have been able to build iproute2 today and >> I am successfully communicating with the driver now being able to set and >> retrieve my queue len! >> >> As I'm working on this I do got a question. I placed the bc_queue_len into >> the struct macvlan_port *port >> since that is where the bc_queue is located today. But when I change and >> retrieve the queue from userspace I realize >> that all macvlan interfaces that share the same physical lowerdev uses the >> same port structure and thus >> the same bc_queue_len. > > Indeed looks like its an ingress attribute. > >> It confused me at first and I'm not sure if that is how it should be. I >> expected the driver to have different >> bc_queues for all macvlan interfaces no matter which lowerdev they were >> using but obviously that is not the case. >> >> It may be a bit confusing to change bc_queue_len on one macvlan and see that >> the change was applied to more than one. >> >> But I'm not sure if I should just move bc_queue_len to the struct >> macvlan_dev either. because then different macvlans will use different queue >> lengths while they still use the same queue. Which may also be considered a >> bit illogical >> >> Let me know what you prefer here! > > I'd record the queue len requested by each interface in their struct > macvlan_dev and then calculate a max over the members to set the actual > value in struct macvlan_port.
That sounds like a good approach to me. I can see that for example mtu is handled in a similar aggregated way. I'll give it a try. Thanks! > > Let me CC some extra people, looks like macvlan does not have a > maintainer.. >
