Commit Graph

10 Commits

Author SHA1 Message Date
Emmanuel Vadot
c5f24f5e0d loader: ip: Do not call getsecs so much
getsecs is very costly, reuse the values we got before.

Fetching a ~30MB kernel with the tftp command use to take ~26 seconds
and now it's ~18 seconds.

Reviewed by:	imp, tsoome
MFC after:	2 weeks
Sponsored by:	Beckhoff Automation GmbH & Co. KG
Differential Revision:	https://reviews.freebsd.org/D33408
2021-12-16 11:50:36 +01:00
Rebecca Cran
d5cee48f3e Wait a maximum of 300 seconds for network send/recv in libsa
The reason for this change is that currently, a send/recv
takes many hours to time out.
This is suboptimal in the bootloader because it means for example
that NFS will take hours to fail before allowing subsequent access
methods such as gzip to be tried.

Setting MAXWAIT to 300 seconds (5 minutes) still allows slow
connections of 1Mb to be used to download a 30MB kernel file.

Sponsored by:	Netflix
Differential Revision:	https://reviews.freebsd.org/D18544
2018-12-20 19:27:46 +00:00
Gleb Smirnoff
9319dded3d Remove unnecessary include from libstand. 2018-10-31 19:59:20 +00:00
Toomas Soome
eba1bc411b libsa: pointer differs in signedness
A small cleanup, fix the argument type and while there, replace (char *)0 with
NULL.
2018-08-01 11:40:52 +00:00
Kyle Evans
ba37055c96 libsa: Partially revert r330023
The removal of tmo >= MAXTMO check should not have been done; this is
specifically what handles timeout if MAXWAIT == 0.

MFC after:	1 week
2018-02-26 18:24:24 +00:00
Kyle Evans
fae9c380ce libsa: Move MAXWAIT from net.h to net.c
It's not a setting that has any effect or use outside of the net.c context.
2018-02-26 18:14:37 +00:00
Kyle Evans
95c61459f3 libsa: Add MAXWAIT to net for establishing max total timeout
Current timeout behavior is to progress in timeout values from MINTMO to
MAXTMO in MINTMO steps before finally timing out. This results in a fairly
long time before operations finally timeout, which may not be ideal for some
use-cases.

Add MAXWAIT that may be configured along with MINTMO/MAXTMO. If we attempt
to start our send/recv cycle over again but MAXWAIT > 0 and MAXWAIT seconds
have already passed, then go ahead and timeout.

This is intended for those that just want to say "timeout after 180 seconds"
rather than calculate and tweak MINTMO/MAXTMO to get their desired timeout.
The default is 0, or "progress from MINTMO to MAXTMO with no exception."

This has been modified since review to allow for it to be defined via CFLAGS
and doing appropriate error checking. Future work may add some Makefile foo
to respect LOADER_NET_MAXWAIT if it's specified in the environment and pass
it in as MAXWAIT accordingly.

Reviewed by:	imp, sbruno, tsoome (all previous version)
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D14389
2018-02-26 18:01:35 +00:00
Kyle Evans
c5b86c3b76 libsa: Consolidate tftp sendrecv into net.c sendrecv
bootp/arp/rarp/rpc all use the sendrecv implementation in net.c. tftp has
its own implementation because it passes an extra parameter into the recv
callback for the received payload type to be held.

These sendrecv implementations are otherwise equivalent, so consolidate
them. The other users of sendrecv won't be using the extra argument to recv,
but this gives us only one place to worry about respecting timeouts and one
consistent timeout behavior.

Tested by:	sbruno
Reviewed by:	sbruno, tsoome
MFC after:	1 week
Differential Revision:	https://reviews.freebsd.org/D14373
2018-02-15 19:49:15 +00:00
Kyle Evans
502b7cf99b libsa: Fix IP recv timeout
readip() doesn't, at the moment, properly indicate to callers that it has
timed out. One can tell that it's timed out if errno == EAGAIN when it
returns, but this is not ideal. Restructure it a little bit to explicitly
set errno to ETIMEDOUT if we've exhausted tleft.

I found two places that care about where it timed out or not: sendrecv in
net.c and sendrecv_tftp. Both are structured to pass smaller timeout values
to readip while tracking a larger timeout. Neither of them were able to do
this properly with readip not indicating ETIMEDOUT, so fix it.

While here, straighten out the time (t/t1) usage in sendrecv_tftp.

This would have manifested itself in periodic failures to NFS/TFTP boot for
no apparent reason because MINTMO/MAXTMO were not actually being respected
properly. Problems were not reported with NFS, only TFTP.

Reported by:	sbruno
Reviewed by:	sbruno, tsoome
MFC after:	3 days
Differential Revision:	https://reviews.freebsd.org/D14350
2018-02-14 15:40:13 +00:00
Warner Losh
ca987d4641 Move sys/boot to stand. Fix all references to new location
Sponsored by:	Netflix
2017-11-14 23:02:19 +00:00