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.