On Mon, Jul 18, 2022 at 02:22:26PM +0200, Enrico Scholz wrote:
> With the tftp "windowsize" option, reordering of udp datagrams becomes
> an issue. Depending on the network topology, this reordering occurs
> several times with large tftp transfers and will heavily reduce the
> transfer speed.
>
> This patch adds a packet cache so that datagrams can be reassembled in
> the correct order.
>
> Because it increases memory usage, it is an Kconfig option.
>
> Signed-off-by: Enrico Scholz <enrico.scholz@xxxxxxxxxxxxxxxxx>
> ---
> fs/Kconfig | 22 +++++++
> fs/tftp.c | 165 +++++++++++++++++++++++++++++++++++++++++++++++++++--
> 2 files changed, 181 insertions(+), 6 deletions(-)
>
> diff --git a/fs/Kconfig b/fs/Kconfig
> index 0c4934285942..02aa25d6abf7 100644
> --- a/fs/Kconfig
> +++ b/fs/Kconfig
> @@ -57,6 +57,28 @@ config FS_TFTP_MAX_WINDOW_SIZE
> Requires tftp "windowsize" (RFC 7440) support on server side
> to have an effect.
>
> +config FS_TFTP_REORDER_CACHE_SIZE
> + int
> + prompt "number of out-of-order tftp packets to be cached"
> + depends on FS_TFTP
> + default 16 if FS_TFTP_MAX_WINDOW_SIZE > 16
> + default 0 if FS_TFTP_MAX_WINDOW_SIZE = 1
> + ## TODO: it should be 'FS_TFTP_MAX_WINDOW_SIZE - 1' but this
> + ## is not supported by Kconfig
> + default FS_TFTP_MAX_WINDOW_SIZE
> + range 0 FS_TFTP_MAX_WINDOW_SIZE
> + help
> + UDP allows reordering of datagrams; with this option,
> + unexpected tftp packets will be cached and later
> + reassembled. This increases stability of the tftp download
> + with the cost of memory (around 1440 bytes per cache
> + element).
> +
> + A value of 0 disables caching.
> +
> + Requires tftp "windowsize" (RFC 7440) support on server side
> + to have an effect.
> +
> config FS_OMAP4_USBBOOT
> bool
> prompt "Filesystem over usb boot"
> diff --git a/fs/tftp.c b/fs/tftp.c
> index f85136f03e22..2c2ff081be51 100644
> --- a/fs/tftp.c
> +++ b/fs/tftp.c
> @@ -68,6 +68,9 @@
> #define TFTP_MTU_SIZE 1432 /* MTU based block size */
> #define TFTP_MAX_WINDOW_SIZE CONFIG_FS_TFTP_MAX_WINDOW_SIZE
>
> +/* size of cache which deals with udp reordering */
> +#define TFTP_WINDOW_CACHE_NUM CONFIG_FS_TFTP_REORDER_CACHE_SIZE
> +
> /* calculate fifo so that it can hold the complete window plus the incoming
> packet. Add some extra space just in case... */
> #define TFTP_FIFO_SIZE (TFTP_MTU_SIZE * TFTP_MAX_WINDOW_SIZE + 2048)
> @@ -76,6 +79,15 @@
>
> static int g_tftp_window_size = TFTP_MAX_WINDOW_SIZE / 1;
>
> +struct tftp_block {
> + uint16_t id;
> + uint8_t data[TFTP_MTU_SIZE];
> +
> + /* len will not exceed TFTP_MTU_SIZE; 14 bits should suffice... */
> + uint16_t len:14;
> + bool valid:1;
> +};
> +
> struct file_priv {
> struct net_connection *tftp_con;
> int push;
> @@ -93,12 +105,49 @@ struct file_priv {
> int blocksize;
> unsigned int windowsize;
> bool is_getattr;
> +#if TFTP_WINDOW_CACHE_NUM > 0
> + struct tftp_block window_cache[TFTP_WINDOW_CACHE_NUM];
> +#endif
> };
Can you use a struct list_head here rather than an array? With that
you can use list_add_sort() to sort the cached packets by id and it
becomes easy to see if the next packet is already there or not without
iterating over the cache multiple times. Also by allocating a tftp_block
dynamically when you need it you only occupy memory for packets that are
received in the wrong order, not for a fixed number of blocks.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
