FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2026-04-12T18:33:07Z 2026-04-12T18:33:07Z Gleb Smirnoff glebius@FreeBSD.org 2026-04-12T18:33:07Z urn:sha1:40dbb06fa73cac37d57563c07e55efd0cabbd488 The inpcb flag INP_DROPPED served two purposes. It was used by TCP and subsystems running on top of TCP as a flag that marks a connection that is now in TCPS_CLOSED, but was in some other state before (not a new-born connection). Create a new TCP flag TF_DISCONNECTED for this purpose. The in_pcbdrop() was a TCP's version of in_pcbdisconnect() that also sets INP_DROPPED. Use in_pcbdisconnect() instead. Second purpose of INP_DROPPED was a negative lookup mask in inp_smr_lock(), as SMR-protected lookup may see inpcbs that had been removed from the hash. We already have had INP_INHASHLIST that marks inpcb that is in hash. Convert it into INP_UNCONNECTED with the opposite meaning. This allows to combine it with INP_FREED for the negative lookup mask. The Chelsio/ToE and kTLS changes are done with some style refactoring, like moving inp/tp assignments up and using macros for that. However, no deep thinking was taken to check if those checks are really needed, it could be that some are not. Reviewed by: rrs Differential Revision: https://reviews.freebsd.org/D56186 2025-09-29T15:19:11Z John Baldwin jhb@FreeBSD.org 2025-09-29T14:55:16Z urn:sha1:19d9a9b15178ed7cfe3f463f43e28cce13fc4f94 Both RDMA (iw_cxgbe) and NVMe offloads use TPT table entries to map transaction tags in incoming PDUs to buffers in host memory permitting direct placement of received data into host memory buffers avoiding copies (iSCSI offload uses a different scheme for mapping tags to host memory). Move the vmem arenas for the supporting card memory regions from iw_cxgbe to the main driver so they can be shared with the NVMe offload driver. In addition, add some helper routines for constructing work requests to update TPT table entries. MFC after: 3 days Sponsored by: Chelsio Communications 2025-09-29T14:26:00Z Navdeep Parhar np@FreeBSD.org 2025-09-29T13:18:07Z urn:sha1:77098268dc397ea86f157f6e66540cd6618e0a05 MFC after: 3 days Sponsored by: Chelsio Communications 2025-09-11T21:10:39Z John Baldwin jhb@FreeBSD.org 2025-09-11T21:10:39Z urn:sha1:5a38857684907c52982787dbac2c5e5c8abfd4f8 Use bitfields to pack tx_credits and plen into a single 32-bit word. Reviewed by: np Sponsored by: Chelsio Communications Differential Revision: https://reviews.freebsd.org/D47759 2024-08-30T15:31:45Z Navdeep Parhar np@FreeBSD.org 2024-08-30T00:23:16Z urn:sha1:9fdb683d92b36cbd20bbd8d61f0c1138f8348dd4 Stop allocating new resources when the RNIC is stopped but continue to allow previously allocated resources to be freed. Note that t4_tom's uld_stop tears down all TOE connections, including those being used for iWARP, and that triggers the cleanup of iWARP resources. Fail post_send/post_recv early too to avoid the SQ doorbell. MFC after: 1 week Sponsored by: Chelsio Communications 2024-08-30T00:58:36Z Navdeep Parhar np@FreeBSD.org 2024-08-30T00:43:43Z urn:sha1:3b4dcc0feb41120017381681d612d3cc21beb1d7 Avoid a pointless assignment while here. MFC after: 1 week Sponsored by: Chelsio Communications 2024-08-29T02:40:04Z Navdeep Parhar np@FreeBSD.org 2024-08-29T02:33:09Z urn:sha1:3f250bb6f05b57890215398767bbb8aa00c888f3 backlog is an int and not a string. While here, fix an adjacent CTR that was spread over two lines even though it fits in one. MFC after: 1 week Sponsored by: Chelsio Communications 2024-08-28T19:19:23Z Navdeep Parhar np@FreeBSD.org 2024-08-28T18:41:10Z urn:sha1:8254a276ad893ae2a1b35fcbbad255f06e29b8c6 Now that suspend/resume is supported by the base driver, a fatal error isn't the only reason that the RNIC can stop abruptly. Also, this state is no longer permanent as it's possible to resume operations after a stop. Rename the flag and associated routines to match the new state of affairs. MFC after: 1 week Sponsored by: Chelsio Communications 2024-08-17T17:38:36Z Navdeep Parhar np@FreeBSD.org 2024-07-22T17:19:58Z urn:sha1:b5332809c633e7e37715f7823a8a8ee9799910a4 eanbled -> enabled MFC after: 3 days 2024-07-22T05:25:08Z Navdeep Parhar np@FreeBSD.org 2024-07-07T00:15:22Z urn:sha1:f1c4ed150334ae2844810a58b7384cb0e3abe664 MFC after: 1 month Sponsored by: Chelsio Communications