Page MenuHomeFreeBSD

ctld: Always declare MaxRecvDataSegmentLength.
ClosedPublic

Authored by jhb on Oct 25 2021, 11:38 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mar 22 2024, 12:47 PM
Unknown Object (File)
Mar 22 2024, 12:47 PM
Unknown Object (File)
Mar 22 2024, 12:07 PM
Unknown Object (File)
Mar 12 2024, 4:01 PM
Unknown Object (File)
Feb 28 2024, 10:22 PM
Unknown Object (File)
Jan 28 2024, 7:18 PM
Unknown Object (File)
Jan 28 2024, 4:31 PM
Unknown Object (File)
Jan 17 2024, 6:03 AM
Subscribers

Details

Summary

This key is Declarative and should always be sent even if the
initiator did not send it's own limit. This is similar to the fix in
fc79cf4fea72 but for the target side.

Sponsored by: Chelsio Communications

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

jhb requested review of this revision.Oct 25 2021, 11:38 PM

I have no objections. Just hope it won't cause more problems than solve.

This revision is now accepted and ready to land.Oct 26 2021, 12:29 AM

PR: 259439

As @mav points out this one is not a functional bug, it just means if the initiator doesn't send MaxRecvDataSegmentLength then send and receive will both just remain at default. It seems logical and simple to me to just send all Declarative keys, but I have no idea if there are some strange initiators that would behave poorly.

I do think it's a bug in that the spec says there is no negotiation for declarative keys, instead that the proposing party just declares them (section 6 in RFC 7143). Just because an initiator doesn't support a large receive buffer doesn't mean it can't stream out larger PDUs on send. Sending large PDUs is easier than receiving large PDUs.

This revision was automatically updated to reflect the committed changes.