On Tue, Aug 13, 2019 at 08:44:09PM +0200, Florian Westphal wrote:
> tests/shell/testcases/transactions/0049huge_0
>
> still fails with ENOBUFS error after endian fix done in
> previous patch. Its enough to increase the scale factor (4)
> on s390x, but rather than continue with these "guess the proper
> size" game, just increase the buffer size and retry up to 3 times.
>
> This makes above test work on s390x.
>
> So, implement what Pablo suggested in the earlier commit:
> We could also explore increasing the buffer and retry if
> mnl_nft_socket_sendmsg() hits ENOBUFS if we ever hit this problem again.
>
> Signed-off-by: Florian Westphal <f...@strlen.de>
> ---
> src/mnl.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/src/mnl.c b/src/mnl.c
> index 97a2e0765189..0c7a4c1fa63f 100644
> --- a/src/mnl.c
> +++ b/src/mnl.c
> @@ -311,6 +311,7 @@ int mnl_batch_talk(struct netlink_ctx *ctx, struct
> list_head *err_list,
> int ret, fd = mnl_socket_get_fd(nl), portid = mnl_socket_get_portid(nl);
> uint32_t iov_len = nftnl_batch_iovec_len(ctx->batch);
> char rcv_buf[MNL_SOCKET_BUFFER_SIZE];
> + unsigned int enobuf_restarts = 0;
> size_t avg_msg_size, batch_size;
> const struct sockaddr_nl snl = {
> .nl_family = AF_NETLINK
> @@ -320,6 +321,7 @@ int mnl_batch_talk(struct netlink_ctx *ctx, struct
> list_head *err_list,
> .tv_usec = 0
> };
> struct iovec iov[iov_len];
> + unsigned int scale = 4;
> struct msghdr msg = {};
> fd_set readfds;
>
> @@ -327,9 +329,7 @@ int mnl_batch_talk(struct netlink_ctx *ctx, struct
> list_head *err_list,
>
> batch_size = mnl_nft_batch_to_msg(ctx, &msg, &snl, iov, iov_len);
> avg_msg_size = div_round_up(batch_size, num_cmds);
> -
> - mnl_set_rcvbuffer(ctx->nft->nf_sock, num_cmds * avg_msg_size * 4);
Leaving this in place does not harm, right? This would speed up things
for x86_64.
It looks like s390 allocates larger page there to accomodate each
netlink event.
All this probing and guess games could be fixed if there is a
getsockopt() to fetch sk->sk_rmem_alloc, this is already exposed in
netlink via /proc. Later :-)
