You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to free the socket resources immediately without any time wait so that I can create no odp pools for timewait timer.
I've found that there's one variable ofp_nolocaltimewait to trigger it.
But the thing is, why we keep the error to 0 that will always create a time wait timer?
Hi,
I guess OFP maintainers are in vacation. Btw, since you are with Nokia, can you check what Matias/Jere/etc. are doing?
Else, I can have a look at this in the following days...
Hi @bogdanPricope
Thx for the information,
Actually I'm not with Nokia.
I'll try to make a if (1) in my project. And keep monitoring what will happen.
Also will be patient to wait for the maintainers' response.
Ok, it looks like this is a remain of the initial integration of BSD code... (one of those things was supposed to be fixed during incubation phase or immediately after). So, there is no better explanation for the 'error' being 0 other than the poor integration.
in the Reference, so the error was meant to check if the peer ip was ours? (Correct me if I was wrong)
Btw, what is the problem with V_tcptw_zone?
A: I still have no idea about it and cannot figure out whether it is an ofp issue or an odp issue.
My project is working with an odp version implemented by the Marvell.
And during the Stress Testing, I can always find that there will be very few possibilities that, an fd keeps open along with its time wait timer active, but the timer will never expire and the callout fails to be called. After some ineffective troubleshooting, I finally decided to close the tcptw_zone
Activity
HsuJv commentedon Aug 17, 2020
Hello?
Anyone here would help?
Thanks.
bogdanPricope commentedon Aug 17, 2020
Hi,
I guess OFP maintainers are in vacation. Btw, since you are with Nokia, can you check what Matias/Jere/etc. are doing?
Else, I can have a look at this in the following days...
HsuJv commentedon Aug 18, 2020
Hi @bogdanPricope
Thx for the information,
Actually I'm not with Nokia.
I'll try to make a
if (1)in my project. And keep monitoring what will happen.Also will be patient to wait for the maintainers' response.
Regards
bogdanPricope commentedon Aug 20, 2020
Oops.. my bad (my confusion).
Ok, it looks like this is a remain of the initial integration of BSD code... (one of those things was supposed to be fixed during incubation phase or immediately after). So, there is no better explanation for the 'error' being 0 other than the poor integration.
Have a look at this code for reference (https://reviews.freebsd.org/file/data/ls656a7hy5wlwjbxe35f/PHID-FILE-cvyptzi6cc3u67kpuqcl/file).
Else, ofp_nolocaltimewait should be (never tried) configurable with ofp_sysctl().
Btw, what is the problem with V_tcptw_zone?
HsuJv commentedon Aug 22, 2020
Thanks a lot for the information
I found that
in the Reference, so the
errorwas meant to check if the peer ip was ours? (Correct me if I was wrong)A: I still have no idea about it and cannot figure out whether it is an ofp issue or an odp issue.
My project is working with an odp version implemented by the Marvell.
And during the Stress Testing, I can always find that there will be very few possibilities that, an fd keeps open along with its time wait timer active, but the timer will never expire and the callout fails to be called. After some ineffective troubleshooting, I finally decided to close the tcptw_zone
bogdanPricope commentedon Aug 23, 2020
I guess the original implementation was like this:
/*
Return 1 if an internet address is for the local host and configured
on one of its interfaces.
*/
int
in_localip(struct in_addr in)
{
struct rm_priotracker in_ifa_tracker;
struct in_ifaddr *ia;
}
TCP side is not so great in OFP. I was planing some updates in my own repo but I did not had the time.