User Details
- User Since
- Mar 10 2018, 1:54 AM (150 w, 2 d)
Yesterday
Looks ok, thanks.
It can be merged there (MFC'd) as well, after a period of a minimum of 3 days. There is no need to submit a separate patch.
Sat, Jan 23
Will the fix be provided as a firmware upgrade or how?
I could commit this change if you don't have someone else around that can do that for you.
Thu, Jan 21
Wouldn't it be easier to always perform the complete phy reset if this is a known hardware issue? Or maye perform it automatically after a normal reset does not work?
I'm afraid that adding an obscure sysctl (obscure for anyone except for the axgbe developers) would be of little use. Unaware users wouldn't have a clue about what to do...
just my 2 cents
Sun, Jan 17
Sat, Jan 16
Fri, Jan 15
Shall I commit this change?
Thu, Jan 14
Looks good to me.
Wed, Jan 13
I added some comments, mostly about readability.
If you tested all the valid combinations of sph_enable and netmap/non-netmap I don't have any objection in this being merged.
Tue, Jan 12
Mon, Jan 11
Sun, Jan 10
Il giorno dom 10 gen 2021 alle ore 13:20 rajesh1.kumar_amd.com (Rajesh
Kumar) <phabric-noreply@freebsd.org> ha scritto:
Sat, Jan 9
Fri, Jan 8
Thanks to both for the clarification.
Il giorno ven 8 gen 2021 alle ore 10:37 rajesh1.kumar_amd.com (Rajesh
Kumar) <phabric-noreply@freebsd.org> ha scritto:
Thu, Jan 7
Are both netmap_test and sph_enable actually necessary? Would it make sense to have only sph_enable, and set isc_nfl = 1 when sph_enable = 0 and isc_nfl = 2 when sph_enable = 1?
If not, I think netmap_test should be called something like single_free_list
Il giorno mer 6 gen 2021 alle ore 20:16 rajesh1.kumar_amd.com (Rajesh
Kumar) <phabric-noreply@freebsd.org> ha scritto:
Il giorno mer 6 gen 2021 alle ore 20:01 rajesh1.kumar_amd.com (Rajesh
Kumar) <phabric-noreply@freebsd.org> ha scritto:
Wed, Jan 6
@rajesh1.kumar_amd.com
Thanks for testing, I'll push this right away.
Tue, Jan 5
Good catch, thanks.
I think the existing line 113 (copying the NS_MOREFRAG flag) was never tested, because it copies the flag the other way around.
Il giorno mar 5 gen 2021 alle ore 07:55 rajesh1.kumar_amd.com (Rajesh
Kumar) <phabric-noreply@freebsd.org> ha scritto:
Sat, Jan 2
Thanks.
I tested it on my side on em(3) and vmx(3) in a VM to look for regressions.
What kind of tests have you done (I guess you are using axgbe)?
Have you tried the pkt-gen -F and -M options on the transmitter side (pkt-gen supports multifrag), and see if a pkt-gen receiver receives the correct traffic?
Do you want me to commit this change?
Tue, Dec 29
LGTM
Thanks!
Mon, Dec 28
Dec 3 2020
I'd say let's go step by step.
First we should merge this patch, which makes sense as is (unless @grehan has some more observations)?
Then we can talk about the other issue in a separate review.
Nov 29 2020
Nov 28 2020
I agree with @grehan , but see my comments.
Nov 26 2020
Not familiar with the code, but it looks ok to me.
Nov 25 2020
Nov 24 2020
Nov 22 2020
Nov 21 2020
Nov 11 2020
Oct 28 2020
Oct 27 2020
Oct 25 2020
Oct 22 2020
Although the change seems legit, it has been reported to cause hangs with netmap pkt-gen.
See:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248652 (from comment 29)
Any idea why this may be the case?
In stable/11, the same logic (two report flags set for every ring) does not cause hangs.
Oct 21 2020
Oct 6 2020
Oct 3 2020
Sep 24 2020
Sep 22 2020
Sep 1 2020
Aug 31 2020
Load the correct patch.
Added assert in iflib_fl_refill().
Improved comment.
Removed assert() at first refill.