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. Let me CC some extra people, looks like macvlan does not have a maintainer..
