[PMTUd] Drop concept of link_mtu and fix data mtu exported values (pass 1)
Cleanup a poor attempt to export all MTU data to the users.
The original idea was to provide information about real link onwire mtu
and max user data mtu (that could be sent on wire without fragmentation)
that adjusted the value for IP protocol, knet header and crypto (if configured).
Effectively there is no use for the real link onwire mtu and it only involves
extra complexity to export lots of extra data to the end user that would have
to redo the calculations internally to gather data mtu.
Also fix the status.mtu value to match knet view of every link.
Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
This fixes an error seen on F23 arm/gcc:
In file included from threads_send_recv.c:26:0:
threads_send_recv.c: In function '_handle_send_to_links_thread':
logging.h:19:2: error: 'savederrno' may be used uninitialized in this
function [-Werror=maybe-uninitialized]
log_msg(knet_h, subsys, KNET_LOG_ERR, fmt, ##args)
^
threads_send_recv.c:475:6: note: 'savederrno' was declared here
int savederrno, docallback = 0;
^
cc1: all warnings being treated as errors
Makefile:843: recipe for target 'libknet_la-threads_send_recv.lo' failed
make[2]: *** [libknet_la-threads_send_recv.lo] Error 1
make[2]: Leaving directory
'/home/jenkins/workspace/kronosnet/arm-fedora-23-gcc/libknet'
Makefile:506: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/home/jenkins/workspace/kronosnet/arm-fedora-23-gcc'
Makefile:417: recipe for target 'all' failed
make: *** [all] Error 2
[PMTUd] fix several issues around PMTUd and improve discovery performances
- Fix a race condition around first time MTU discovery where MTU value
would be out of the wazooo
- Fix a case where onwire MTU value would be smaller than crypto header
and generate errors
- Make MTU value a decision factor if a link is usable or not.
If MTU is not valid (either the discovery process failed) or
the value is not sane, the link will be removed from the available
data link pool till the problem is resolved. Once the problem is
solved the link will recover automatically.
- Have link up/down status trigger a PMTUd process to speed up
detection.
- Add ability to detect smaller MTU than minimum defined by protocol.
- Improve error reporting across the board.
- Make PMTUd timeout dynamic based on current link latency. This change
makes detection of small MTU very fast.
- Sanity check values returned by PMTUD to be in range between
minimum MTU defined by given protocol and maximum that knet can handle.
- Trigger host cache reculaculation on MTU validity change to reduce
risk of packet loss on bad links.
Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
In file included from /usr/include/stdio.h:936:0,
from ping_test.c:12: In function ‘snprintf’,
inlined from ‘main’ at ping_test.c:504:3: /usr/include/bits/stdio2.h:64:10: error: call to
__builtin___snprintf_chk will always overflow destination buffer [-Werror]
return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
[send/recv] rework handling of 0 byte read/write on local sockets
considering there is no obvious use case trying to send 0 byte packets
and that 0 byte packtes are filtered by iovec calls across the all
code, there is no point trying to handle 0 byte differently from
any other socket error.
this commit makes sure that every time there is an error (-1) or a 0
byte read from the locally provided sockets, a call back is issued.
on read errors (-1) the socket will be removed from the epoll
to avoid spinning and it is safe to call knet_handle_remove_datafd
afterwards to remove it completely.
it is now mandatory to enable a sock_notify callback before adding
datafd.
read libknet.h carefully on what the callback is supposed to do
based on the type of socket your application is adding.
Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
[global] add support for multiple local sockets/fds
WARNING: this commit changes API and onwire protocol
It is now possible to configure multiple local sockets to send/recv
data over the same knet handle.
to every send/recv socket a channel is assigned that behaves more
or less like a VLAN.
hostA channel 0 will be delivered to datafd on hostB channel 0
hostA channel 1 to hostB channel 1
etc.
It is possible to configure up to 32 channel, but there is space
to increase this number if necessary.
New API calls:
knet_handle_add_datafd
knet_handle_remove_datafd
knet_handle_enable_sock_notify
knet_handle_get_channel
knet_handle_get_datafd
Notification has been added in cases where a local socket is the result
of accepting a tcp connection that gets disconnected and corrective
action needs to be taken by the application.
Changed API calls:
knet_handle_new
knet_recv
knet_send
knet_handle_enable_filter
onwire changes:
add one byte to transport channel information
channel information are also passed down to the dst_host_filter
in the event the application has needs to modify that on TX/RX
events.
Internal changes:
cleanup how sockpairs are handled in general to make it simpler
to map application side and internal side.
NOTE: callback function has not been properly tested.
Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
splitting frags across multiple links is not worth the complexity of
the code or the complexity in re-assemblying the packet if links
are at different speed/status
Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
HOSTINFO packets are nothing more than special cased DATA packets.
The contents of HOSTINFO is stored inside DATA of DATA packets and
up to the point where we need to use the HOSTINFO data, we need
to treat the packets as DATA for defragmentation and deduplication.
This also fixes a problem when using round-robin and active switching
policy where the HOSTINFO exchange would loop forever in a storm
because duplicate pckts were being handled at once.
Signed-off-by: Fabio M. Di Nitto <fdinitto@redhat.com>
[crypto] align crypto_authenticate_and_decrypt API to crypto_encrypt_and_sign
2 issues solved by this change:
1) API were different and crypto_authenticate_and_decrypt would trash the
incoming packet, that we might want to keep for later usage
(re-switch for example)
2) By using an extre pre-allocated buffer while decrypting incoming packets
we save a whole memcpy and that reduces latency on crypto communications: