Page MenuHomeFreeBSD

unix/dgram: reduce mbuf chain traversals in send(2) and recv(2)
ClosedPublic

Authored by glebius on May 23 2022, 9:02 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Sep 18, 7:44 PM
Unknown Object (File)
Wed, Sep 18, 12:03 PM
Unknown Object (File)
Thu, Sep 5, 3:56 PM
Unknown Object (File)
Aug 21 2024, 4:16 PM
Unknown Object (File)
Aug 9 2024, 7:35 AM
Unknown Object (File)
Aug 4 2024, 2:00 AM
Unknown Object (File)
Aug 4 2024, 2:00 AM
Unknown Object (File)
Aug 4 2024, 2:00 AM
Subscribers

Details

Summary

o Use m_pkthdr.memlen from m_uiotombuf()
o Modify unp_internalize() to keep track of allocated space and memory

as well as pointer to the last buffer.

o Modify unp_addsockcred() to keep track of allocated space and memory

as well as pointer to the last buffer.

o Record the datagram len/memlen in the first (from) mbuf of the chain

in uipc_sosend_dgram() and reuse it in uipc_soreceive_dgram().

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 45813
Build 42701: arc lint + arc unit

Event Timeline

Note: this patch is a step towards D35303.

sys/kern/uipc_usrreq.c
2699–2707

Here we check *controlp != NULL but above we assume *controlp is not NULL. Can this check be dropped?

2809–2813

If control is NULL, then *clast is uninitialized and we don't update it here. Though, the caller doesn't seem to use clast anyway...

sys/kern/uipc_usrreq.c
2699–2707

You are right. This is true after 24df85d29a309522a4878bdf382696c7319ce898 and 579b45e203287f78cfb4a91491893b2919aa9ec4. I will commit that separately.

glebius added inline comments.
sys/kern/uipc_usrreq.c
2809–2813

Yes, this is by design. Caller supplies &clast only if it supplies control, just in case if unp_addsockcred() decides to modify the chain and delete last mbuf. If there is nothing to modify, then there is nothing to update.

glebius added inline comments.
sys/kern/uipc_usrreq.c
2699–2707

No, this check is still required. In the beginning of SCM_RIGHTS case there is condition when we break out without calling sbcreatecontrol(). In this case we would set it to NULL and panic on next iteration.

sys/kern/uipc_usrreq.c
2699–2707

Can be triggered by SCM_RIGHTS with zero descriptors.

sys/kern/uipc_usrreq.c
2699–2707

Here we check *controlp != NULL but above we assume *controlp is not NULL. Can this check be dropped?

You are right. This is true after 24df85d29a309522a4878bdf382696c7319ce898 and 579b45e203287f78cfb4a91491893b2919aa9ec4. I will commit that separately.

No, this check is still required. In the beginning of SCM_RIGHTS case there is condition when we break out without calling sbcreatecontrol(). In this case we would set it to NULL and panic on next iteration.

Okay. One week ago I fell into the same wrong conclusion as you did, that *controlp != NULL is not needed. I quickly committed that (actually smashed into other useful commit) and continued putting changes on top of that. And then spent extra hours trying to figure out why unix_passfd:empty_rights started to panic. So, I decided to rewrite this cycle, so a third person won't fall into the same confusion: D35375

sys/kern/uipc_usrreq.c
2699–2707

Ok, I will wait until this is rebased on D35375 before looking further.

This revision is now accepted and ready to land.Jun 3 2022, 6:43 PM
This revision now requires review to proceed.Jun 9 2022, 9:51 PM
This revision was not accepted when it landed; it landed in state Needs Review.Jun 24 2022, 4:11 PM
This revision was automatically updated to reflect the committed changes.