郑国勇 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.
>
