Please read the links we already shared with you!!! No MIME, no links, no compression, no attachments. Just plain text https://www.kernel.org/doc/html/latest/process/submitting-patches.html#no-mime-no-links-no-compression-no-attachments-just-plain-text On Tue, 11 Feb 2025 at 06:24, 吴俊南 <junnan01.wu@xxxxxxxxxxx> wrote: > > Hello leonardi and stefanha： > > Thanks for your review. And I will add other maintainers CCd in > next push. And I want to discuss more about the second patch. Why are you sending a v2 if we didn't reach an agreement on the second patch? > > > Firstly, we think our scenarios are quite different. These are the information that should be put in the commit description. We are not oracles imagining scenarios.... > Our scenario is virtio-vsock deployed in embeded environment, and > suspend to ram is for order to allow system run at low power > consumption. In this scenario, the AF_VSOCK socket is created by Guest > upper application and don't close after driver freeze. Once restore, > the connection which are communicating before will be failed. It will > cause that upper application based on vsock connect failed. In this > mode, guest haven't received the event to close all connections. > That's difference with you metioned. I mentioned the second scenario just as an example. > > > Secondly, refer to socket based on virtio-net device, they don't > close connected during freeze. > > Here we did a test that: > > Start iperf server based on virtio-net in Host. > Start iperf client based on virtio-net in Guest and keep > communicating with server. > Suspend Guest > Resume Guest. > > Here in virtio-net, the iperf communication is still working after > these steps. But iperf based on vsock will fail. We think it > should keep same reaction with virtio-net I agree that it would be cool, but this patch is not the right way as I explained in the previous email. virtio-net can easily discard packets because it's an ethernet device. As I already explained, virtio-vsock guarantees ordering and delivery of packets via virtqueues, if these disappear, you have to add something on top that keeps track of undelivered packets. > > > Thirdly, accroding to virtio-spec, vsock facilitates data transfer > between the guest and device without using the Ethernet or IP > protocols. What does this have to do with packet loss? It simply says that vsock does not need a classic TCP/IP stack, but directly connects guest and host sockets via virtqueues. > > Therefore we think packets lost is acceptable for it, and it is > not necessary to keep those packet during suspend flow. Where did you read that packet loss is acceptable?
