[Intel-wired-lan] [PATCH v3 04/11] igc: Add interrupt support

[Shannon Nelson]

On 7/12/2018 1:57 AM, Neftin, Sasha wrote:
> On 7/3/2018 11:25, Neftin, Sasha wrote:
>> On 6/28/2018 02:42, Shannon Nelson wrote:
>>> On 6/24/2018 1:45 AM, Sasha Neftin wrote:
>>>> This patch set adds interrupt support for the igc interfaces.

[...]

>>>
> I need check it. currently it is consistent with our previously driver.

I understand the desire to keep with what is working in other drivers, 
but in some cases they are showing signs of age and might lead you astray.

[...]

>>>> +
>>>> +        if (q_vector->rx.ring && q_vector->tx.ring)
>>>> +            sprintf(q_vector->name, "%s-TxRx-%u", netdev->name,
>>>> +                q_vector->rx.ring->queue_index);
>>>> +        else if (q_vector->tx.ring)
>>>> +            sprintf(q_vector->name, "%s-tx-%u", netdev->name,
>>>> +                q_vector->tx.ring->queue_index);
>>>> +        else if (q_vector->rx.ring)
>>>> +            sprintf(q_vector->name, "%s-rx-%u", netdev->name,
>>>> +                q_vector->rx.ring->queue_index);
>>>
>>> Is there any reason to support the tx and rx queues split on 
>>> different interrupts?
>>>
> i stayed align with previos driver style. any benefit from change it?

With RSS putting certain incoming traffic on one particular 
Rx/interrupt/CPU, it's good to keep the outgoing response traffic on the 
same Tx/interrupt/CPU so that you don't have to move data to a different 
CPU and cache.  This is a general case thing, of course, and I'm sure 
there are examples of where Tx and Rx on separate interrupts is a useful 
thing.  However, are the target platforms for this device going to want 
to spread the Tx and Rx queues across different interrupts?

If you can assume that queues are always in pairs on the interrupts you 
can simplify a bunch of code, which is always a good thing.  You'll want 
to balance the simplified code against user and design requirements.

sln