Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH] nl80211: Support mgmt frame unregistrations
To:     Johannes Berg <johannes@sipsolutions.net>,
        linux-wireless@vger.kernel.org
References: <20190904162239.2075-1-denkenz@gmail.com>
 <7a089d5ec94da92fc0c1255a2afa6ae0d8b8aaa4.camel@sipsolutions.net>
From:   Denis Kenzior <denkenz@gmail.com>
Message-ID: <fcb56c09-d9de-c086-ff27-75e3bd1da6a8@gmail.com>
Date:   Wed, 11 Sep 2019 08:33:34 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <7a089d5ec94da92fc0c1255a2afa6ae0d8b8aaa4.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hi Johannes,

On 9/11/19 3:53 AM, Johannes Berg wrote:
> On Wed, 2019-09-04 at 11:22 -0500, Denis Kenzior wrote:
>> To state another way, it is
>> currently not possible to write a userspace application that utilizes a
>> single nl80211 genl socket, instead it must open multiple genl sockets
>> for multiple wdevs on multiple phys.
> 
> I don't see how this is too onerous for the application, every
> application is basically going to have an event loop anyway.

What does having an event loop have to do with this? :)

> 
> Thus, I don't really see any reason for us to add a bunch of code just
> to make an application track fewer file descriptors - we need to have
> the cleanup on close already anyway, so why not actually exercise those
> code paths?

I just find this super wasteful.  We have instances where we need to 
register to a single management frame temporarily.  So opening and 
closing a socket just for that is just bloat.

> 
> I do note that with the "unregister on iftype change" patch you could
> switch to an unsupported type and reach this, but I don't think you'd
> want to rely on that :-)
> 

Not sure I understand?

> Possibly I could imagine a reason for this if you needed a single socket
> for functional reason, but you're not really giving any such reason. I
> could imagine that there might be races, but I'm having a hard time
> coming up with a scenario where they actually matter ... if you really
> really get a race between e.g. RX-AUTH and INTERFACE-DEL you'll try to
> do some operations that will just fail, but so what?

- Waste on the userspace side.  Typically userspace uses some sort of 
abstraction for tracking genl sockets.  So it has to allocate buffers, 
etc.  Can we get around that? Sure, but you're not winning any arguments 
that the nl80211 is 'nice to use' that way.

- Waste on the kernel side.  Each socket costs something for the kernel, 
makes things harder to audit, etc, etc.  And we now have people trying 
to stuff 15+ cards into a single system.  Each card might have multiple 
netdevs.  Each netdev might need multiple file descriptors open.  So 
we're ending up needing 30-60, or whatever file descriptors when we 
could just as easily use 1.  Extreme case? Sure, but I like to remove 
bloat whenever / wherever I can.

Regards,
-Denis