From: John Fastabend <john.fastabend@gmail.com>
To: 郑国勇 <zhenggy@chinatelecom.cn>,
john.fastabend@gmail.com, jakub@cloudflare.com,
bpf@vger.kernel.org
Subject: RE: [issue]: sockmap restrain send if receiver block
Date: Mon, 17 Jun 2024 10:07:20 -0700 [thread overview]
Message-ID: <66706d48967f3_1c38c208e5@john.notmuch> (raw)
In-Reply-To: <42dd5ee4-fb01-4b84-9418-65adb7480138@chinatelecom.cn>
郑国勇 wrote:
> hi, In sockmap case, when sender send msg, In function sk_psock_queue_msg(), it will put the msg into the receiver psock ingress_msg queue, and wakeup receiver to receive.
>
Whats the protocol? The TCP case tcp_bpf_sendmsg() is checking
sk_stream_memory_free() and will do sk_stream_wait_memory() if under
memory pressure. This should handle sending case with lots of data
queued up on the sk.
On the redirect ingress case we do this,
sk_psock_handle_skb()
sk_psock_skb_ingress()
sk_psock_create_ingress_msg()
There sk_psock_create_ingress_msg() should check the rcvbuf of the
receiving socket and shouldn't create a msg if its under memory pressure.
If its an ingress_self case we do a skb_set_owner_r which should (?) push
back on the memory side through sk_mem_charge().
Seems like I'm missing some case then if we are hitting this. What protocol
and what is the BPF program? Is it a sender redirect? I guess more details
might make it obvious to me.
> sender can always send msg but not aware the receiver psock ingress_msg queue size. In mortally case, when receiver not receive again due to the application bug,
>
> sender can contiunous send msg unti system memory not enough. If this happen, it will influence the whole system.
>
> my question is: is there a better solution for this case? just like tcp use sk_sendbuf to limit the sender to send agagin if receiver is block.
The sender shouldn't be able to have more outstanding data than the
socket memory allows. After the redirect the skb/msg should be
charged to the receiving socket though. Agree sk_sendbuf should
limit sender. Maybe the test is not TCP protocol and we missed
adding the limits to UDP/AF_UNIX/etc?
>
> thanks very much.
>
next prev parent reply other threads:[~2024-06-17 17:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-17 2:01 [issue]: sockmap restrain send if receiver block 郑国勇
2024-06-17 17:07 ` John Fastabend [this message]
2024-06-18 7:47 ` zhengguoyong
2024-06-18 8:08 ` zhengguoyong
2024-06-21 6:44 ` zhengguoyong
2024-06-25 19:51 ` John Fastabend
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=66706d48967f3_1c38c208e5@john.notmuch \
--to=john.fastabend@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=jakub@cloudflare.com \
--cc=zhenggy@chinatelecom.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox