On 3/4/2022 1:23 AM, Zhang, Qi Z wrote:


-----Original Message-----
From: Yigit, Ferruh <[email protected]>
Sent: Friday, March 4, 2022 12:44 AM
To: Zhang, Qi Z <[email protected]>; Feifei Wang <[email protected]>;
Xing, Beilei <[email protected]>; David Christensen
<[email protected]>; Richardson, Bruce <[email protected]>;
Ananyev, Konstantin <[email protected]>; Ruifeng Wang
<[email protected]>
Cc: [email protected]; [email protected]; Honnappa Nagarahalli
<[email protected]>; Thomas Monjalon
<[email protected]>; David Marchand <[email protected]>
Subject: Re: [PATCH v1] net/i40e: remove redundant number of packets check

On 3/3/2022 2:28 AM, Zhang, Qi Z wrote:


-----Original Message-----
From: Feifei Wang <[email protected]>
Sent: Thursday, March 3, 2022 9:54 AM
To: Xing, Beilei <[email protected]>; David Christensen
<[email protected]>; Richardson, Bruce
<[email protected]>; Ananyev, Konstantin
<[email protected]>; Ruifeng Wang <[email protected]>
Cc: [email protected]; [email protected]; Feifei Wang <[email protected]>;
Honnappa Nagarahalli <[email protected]>
Subject: [PATCH v1] net/i40e: remove redundant number of packets
check

For i40e_xmit_pkts_vec_xx function, it checks nb_pkts to ensure
nb_pkts does not cross rs_thresh.

However, in i40e_xmit_fixed_burst_vec_xx function, this check will be
performed again. To improve code, delete this redundant check.

Suggested-by: Honnappa Nagarahalli <[email protected]>
Signed-off-by: Feifei Wang <[email protected]>
Reviewed-by: Ruifeng Wang <[email protected]>

Applied to dpdk-next-net-intel.


Hi Qi,

This patch is not acked by the i40e maintainers.

And this is changing the datapath for the -rc3, two weeks before the release. Is
it tested enough?

What is the gain with this patch, I don't see any numbers in the commit log.
If the gain is small, can we postpone this patch to next release instead of 
getting
it for -rc3?

The patch applied the same thing as below which I have reviewed.
https://patchwork.dpdk.org/project/dpdk/patch/[email protected]/

I didn't see the risk of having it, and I will add a "reviewed-by" to avoid 
confusion, but if you think it's risky, we can still defer it to next-net.


Code change looks simple, but risk is more theoretical
to get a datapath code optimization close to the release,
and Feifei reported that there is no visible performance
gain.
So I think safer to postpone to next release if you don't
object.

Reply via email to