Re: [PATCH] net: tuntap: add ioctl() TUNGETQUEUEINDX to fetch queue index

[Willem de Bruijn]

> > So I guess an application that owns all the queues could keep track of
> > the queue-id to FD mapping. But it is not trivial, nor defined ABI
> > behavior.
> >
> > Querying the queue_id as in the proposed patch might not solve the
> > challenge, though. Since an FD's queue-id may change simply because
> Yes, when I asked about those eBPF thing, I thought I don’t need the queue id in those ebpf. It turns out a misunderstanding.
> Do we all agree that no matter which filter or steering method we used here, we need a method to query queue index assigned with a fd?

That depends how you intend to use it. And in particular how to work
around the issue of IDs not being stable. Without solving that, it
seems like an impractical and even dangerous -because easy to misuse-
interface.

> > another queue was detached. So this would have to be queried on each
> > detach.
> >
> Thank you Jason. That is why I mentioned I may need to submit another patch to bind the queue index with a flow.
>
> I think here is a good chance to discuss about this.
> I think from the design, the number of queue was a fixed number in those hardware devices? Also for those remote processor type wireless device(I think those are the modem devices).
> The way invoked with hash in every packet could consume lots of CPU times. And it is not necessary to track every packet.

rxhash based steering is common. There needs to be a strong(er) reason
to implement an alternative.

> Could I add another property in struct tun_file and steering program return wanted value. Then it is application’s work to keep this new property unique.

I don't entirely follow this suggestion?

> > I suppose one underlying question is how important is the mapping of
> > flows to specific queue-id's? Is it a problem if the destination queue
> > for a flow changes mid-stream?
> Yes, it matters. Or why I want to use this feature. From all the open source VPN I know, neither enabled this multiqueu feature nor create more than one queue for it.
> And virtual machine would use the tap at the most time(they want to emulate a real nic).
> So basically this multiple queue feature was kind of useless for the VPN usage.
> If the filter can’t work atomically here, which would lead to unwanted packets transmitted to the wrong thread.

What exactly is the issue if a flow migrates from one queue to
another? There may be some OOO arrival. But these configuration
changes are rare events.