aboutgitcodebugslistschat
path: root/pasta.c
diff options
context:
space:
mode:
authorDavid Gibson <david@gibson.dropbear.id.au>2023-08-03 17:19:51 +1000
committerStefano Brivio <sbrivio@redhat.com>2023-08-04 01:28:26 +0200
commit99ddd7ce837f589998f2bf8ce91c0bbe74a319a0 (patch)
tree6bd942e8a451cca2f31a634936e5954ccb6a5d7a /pasta.c
parent8ec757d0035cdffaca4d6d01093c1f32dc7c9743 (diff)
downloadpasst-99ddd7ce837f589998f2bf8ce91c0bbe74a319a0.tar
passt-99ddd7ce837f589998f2bf8ce91c0bbe74a319a0.tar.gz
passt-99ddd7ce837f589998f2bf8ce91c0bbe74a319a0.tar.bz2
passt-99ddd7ce837f589998f2bf8ce91c0bbe74a319a0.tar.lz
passt-99ddd7ce837f589998f2bf8ce91c0bbe74a319a0.tar.xz
passt-99ddd7ce837f589998f2bf8ce91c0bbe74a319a0.tar.zst
passt-99ddd7ce837f589998f2bf8ce91c0bbe74a319a0.zip
netlink: Split nl_req() to allow processing multiple response datagrams
Currently nl_req() sends the request, and receives a single response datagram which we then process. However, a single request can result in multiple response datagrams. That happens nearly all the time for DUMP requests, where the 'DONE' message usually comes in a second datagram after the NEW{LINK|ADDR|ROUTE} messages. It can also happen if there are just too many objects to dump in a single datagram. Allow our netlink code to process multiple response datagrams by splitting nl_req() into three different helpers: nl_send() just sends a request, without getting a response. nl_status() checks a single message to see if it indicates the end of the reponses for our request. nl_next() moves onto the next response message, whether it's in a datagram we already received or we need to recv() a new one. We also add a 'for'-style macro to use these to step through every response message to a request across multiple datagrams. While we're at it, be more thourough with checking that our sequence numbers are in sync. Link: https://bugs.passt.top/show_bug.cgi?id=67 Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'pasta.c')
0 files changed, 0 insertions, 0 deletions