r8169: Discussion on implementing RSS support for r8169

r8169: Discussion on implementing RSS support for r8169

[Javen]

Hi, Heiner

We are now planning to implement RSS support on r8169 driver. This will require significant changes to the existing driver architecture, so we want to discuss it with you.

Based on our vendor driver which can be fetched from Realtek, the key modifications will include:

	1. Enable msix and updating the irq allocation mechanism
	2. Support multiple rx/tx queues
	3. Register multiple napi and update new interrupt mapping(isr/imr) for multi-queue
	4. Implement rx msix poll and rx interrupt function
	5. Implement ethtool callbacks for rss configuration

Should we submit the changes above separately or submit them all at once? Or do you have any other suggestions?

We want to align with you on the development and submission approach. 

Best regards,

Javen Xu

Re: r8169: Discussion on implementing RSS support for r8169

[Andrew Lunn]

On Thu, Mar 19, 2026 at 08:56:58AM +0000, Javen wrote:
> Hi, Heiner
> 
> We are now planning to implement RSS support on r8169 driver. This will require significant changes to the existing driver architecture, so we want to discuss it with you.
> 
> Based on our vendor driver which can be fetched from Realtek, the key modifications will include:
> 
> 	1. Enable msix and updating the irq allocation mechanism
> 	2. Support multiple rx/tx queues
> 	3. Register multiple napi and update new interrupt mapping(isr/imr) for multi-queue
> 	4. Implement rx msix poll and rx interrupt function
> 	5. Implement ethtool callbacks for rss configuration
> 
> Should we submit the changes above separately or submit them all at once? Or do you have any other suggestions?

You generally want lots of small patches, each with a good commit
message, which are obviously correct. Given the limit of 15 patches in
one series, you probably need to break it up into a number of series.

Also, having small patches makes git bisect more useful when you
break stuff.

      Andrew

Re: r8169: Discussion on implementing RSS support for r8169

[Heiner Kallweit]

On 19.03.2026 09:56, Javen wrote:
> Hi, Heiner
> 
> We are now planning to implement RSS support on r8169 driver. This will require significant changes to the existing driver architecture, so we want to discuss it with you.
> 
Thanks for the question.
I also once considered this, but decided against it, as I didn't see enough benefit justifying the
significantly increased complexity of the driver. Even with a N100-based mini-pc I can easily
saturate a 2.5Gbps link with the driver as-is.
Any specific reason why you consider adding RSS support? Would be good to see a performance comparison
as basis for a decision on for which chip versions RSS may provide a significant benefit.

> Based on our vendor driver which can be fetched from Realtek, the key modifications will include:
> 
> 	1. Enable msix and updating the irq allocation mechanism
> 	2. Support multiple rx/tx queues
> 	3. Register multiple napi and update new interrupt mapping(isr/imr) for multi-queue
> 	4. Implement rx msix poll and rx interrupt function
> 	5. Implement ethtool callbacks for rss configuration
> 
> Should we submit the changes above separately or submit them all at once? Or do you have any other suggestions?
> 
As Andrew already said, please submit the patches in smaller, reviewable, chunks.
Best tagged as RFC.

> We want to align with you on the development and submission approach. 
> 
> Best regards,
> 
> Javen Xu

Heiner

RE: r8169: Discussion on implementing RSS support for r8169

[Javen]

>On 19.03.2026 09:56, Javen wrote:
>> Hi, Heiner
>>
>> We are now planning to implement RSS support on r8169 driver. This will
>require significant changes to the existing driver architecture, so we want to
>discuss it with you.
>>
>Thanks for the question.
>I also once considered this, but decided against it, as I didn't see enough
>benefit justifying the significantly increased complexity of the driver. Even
>with a N100-based mini-pc I can easily saturate a 2.5Gbps link with the driver
>as-is.
>Any specific reason why you consider adding RSS support? Would be good to
>see a performance comparison as basis for a decision on for which chip
>versions RSS may provide a significant benefit.
>

The primary beneft of adding rss here is to reduce cpu load per core.

Since I currently only have one RTL8111ep and one RTL8127, I'm going to do a simple test.

Based on my iperf test from RTL8111ep to RTL8127:
	1. With rss: cpu load is distributed across 4 cores(1% ~ 2% each)
	2. Without rss: cpu load is concentrated on a single core(7% ~ 8%)

If test from RTL8127 to RTL8127, especially on platforms with weaker cpu, disabling rss will easily lead to cpu overload. 
That's the main reason we consider adding rss support for RTL8127.

I will show the result from RTL8127 to RTL8127 when I submit rss patch.

Thanks,
Javen Xu

>> Based on our vendor driver which can be fetched from Realtek, the key
>modifications will include:
>>
>>       1. Enable msix and updating the irq allocation mechanism
>>       2. Support multiple rx/tx queues
>>       3. Register multiple napi and update new interrupt mapping(isr/imr) for
>multi-queue
>>       4. Implement rx msix poll and rx interrupt function
>>       5. Implement ethtool callbacks for rss configuration
>>
>> Should we submit the changes above separately or submit them all at once?
>Or do you have any other suggestions?
>>
>As Andrew already said, please submit the patches in smaller, reviewable,
>chunks.
>Best tagged as RFC.
>
>> We want to align with you on the development and submission approach.
>>
>> Best regards,
>>
>> Javen Xu
>
>Heiner

Re: r8169: Discussion on implementing RSS support for r8169

[Heiner Kallweit]

On 20.03.2026 04:22, Javen wrote:
>> On 19.03.2026 09:56, Javen wrote:
>>> Hi, Heiner
>>>
>>> We are now planning to implement RSS support on r8169 driver. This will
>> require significant changes to the existing driver architecture, so we want to
>> discuss it with you.
>>>
>> Thanks for the question.
>> I also once considered this, but decided against it, as I didn't see enough
>> benefit justifying the significantly increased complexity of the driver. Even
>> with a N100-based mini-pc I can easily saturate a 2.5Gbps link with the driver
>> as-is.
>> Any specific reason why you consider adding RSS support? Would be good to
>> see a performance comparison as basis for a decision on for which chip
>> versions RSS may provide a significant benefit.
>>
> 
> The primary beneft of adding rss here is to reduce cpu load per core.
> 
> Since I currently only have one RTL8111ep and one RTL8127, I'm going to do a simple test.
> 
> Based on my iperf test from RTL8111ep to RTL8127:
> 	1. With rss: cpu load is distributed across 4 cores(1% ~ 2% each)
> 	2. Without rss: cpu load is concentrated on a single core(7% ~ 8%)
> 
In sum it's the same, so we don't gain anything. More the opposite, we keep
more CPU's busy and don't allow them to transition to deeper power-saving states.

> If test from RTL8127 to RTL8127, especially on platforms with weaker cpu, disabling rss will easily lead to cpu overload. 

I could imagine this at a rate of 10Gbps, but still would like to see some
numbers. However, question is how realistic are use cases where a 10Gbps link
is used (and fully utilized) on a system with a weak cpu.

> That's the main reason we consider adding rss support for RTL8127.
> 
> I will show the result from RTL8127 to RTL8127 when I submit rss patch.
> 
Yes, please.

> Thanks,
> Javen Xu
> 
>>> Based on our vendor driver which can be fetched from Realtek, the key
>> modifications will include:
>>>
>>>       1. Enable msix and updating the irq allocation mechanism
>>>       2. Support multiple rx/tx queues
>>>       3. Register multiple napi and update new interrupt mapping(isr/imr) for
>> multi-queue
>>>       4. Implement rx msix poll and rx interrupt function
>>>       5. Implement ethtool callbacks for rss configuration
>>>
>>> Should we submit the changes above separately or submit them all at once?
>> Or do you have any other suggestions?
>>>
>> As Andrew already said, please submit the patches in smaller, reviewable,
>> chunks.
>> Best tagged as RFC.
>>
>>> We want to align with you on the development and submission approach.
>>>
>>> Best regards,
>>>
>>> Javen Xu
>>
>> Heiner