On 7/23/19 4:54 PM, Saeed Mahameed wrote:

On Tue, 2019-07-23 at 16:06 -0700, David Miller wrote:

quoted

From: Shannon Nelson <redacted>
Date: Tue, 23 Jul 2019 15:50:43 -0700

quoted

On 7/23/19 2:33 PM, David Miller wrote:

quoted

Generally interface address changes are expected to be
synchronous.

Yeah, this bothers me a bit as well, but the address change calls
come
in under spin_lock_bh(), and I'm reluctant to make an AdminQ call
under the _bh that could block for a few seconds.

So it's not about memory allocation but rather the fact that the
device
might take a while to complete?

Can you start the operation synchronously yet complete it async?

The driver is doing busy polling on command completion, doing only busy
polling on completion status in the deferred work will not be much
different than what they have now..

async completion will only make since if the hardware supports
interrupt based (MSI-x) command completion.

Actually, there are two different command paths - one for basic 
low-level setup, and one for more advanced work:
- dev_cmd does indeed do polling on PCI register space, and we try to 
keep this to a minimum
- adminq does a wait_for_completion_timeout() which gets completed in an 
MSI-x handler

The rx_mode related work goes through adminq.

Yes, it could be made async, but would the extra logic needed buy us 
that much?  We already know this model works in other drivers.  We 
wouldn't get the address into the hardware any quicker, and we still 
wouldn't get any errors from the request back to the original call.

sln