Decouple the send and receive limits on the amount of data in a single
iSCSI PDU. MaxRecvDataSegmentLength is declarative, not negotiated, and
is direction-specific so there is no reason for both ends to limit
themselves to the same min(initiator, target) value in both directions.
Allow iSCSI drivers to report their send, receive, first burst, and max
burst limits explicitly instead of using hardcoded values or trying to
derive all of them from the receive limit (which was the only limit
reported by the drivers prior to this change).
Display the send and receive limits separately in the userspace iSCSI
utilities.
Reviewed by: jpaetzel@ (earlier version), trasz@
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7279
The target must reply with the selected value of MaxBurstSize instead of
just echoing back the initiator's offered value.
Reviewed by: mav@
Sponsored by: Chelsio Communications
Differential Revision: https://reviews.freebsd.org/D7278
These are no longer needed after the recent 'beforebuild: depend' changes
and hooking DIRDEPS_BUILD into a subset of FAST_DEPEND which supports
skipping 'make depend'.
Sponsored by: EMC / Isilon Storage Division
This fixes connection errors for some initiators not starting CmdSN
from zero.
While there, fix wrong status details reported for couple errors.
MFC after: 3 days
This is not properly respecting WITHOUT or ARCH dependencies in target/.
Doing so requires a massive effort to rework targets/ to do so. A
better approach will be to either include the SUBDIR Makefiles directly
and map to DIRDEPS or just dynamically lookup the SUBDIR. These lose
the benefit of having a userland/lib, userland/libexec, etc, though and
results in a massive package. The current implementation of targets/ is
very unmaintainable.
Currently rescue/rescue and sys/modules are still not connected.
Sponsored by: EMC / Isilon Storage Division
While CTL has concept of port options, used at least for iSCSI ports now,
before this change it was impossible to set them manually. There still
no user-configurable port options now, but I am planning to change that.
basics. The more complicated cases - like how to use physical
ports - are explained later, in the "EXAMPLES" section.
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
Its idea was to be a simple initiator and execute several commands from
kernel level, but FreeBSD never had consumer for that functionality,
while its implementation polluted many unrelated places..
This allows ctld to work with isp(4) virtual ports, specifying them as
isp0/1, isp0/2, etc. There are still problems on isp(4) layer with
disabling those ports after enabling, but hopefully they can be fixed.
MFC after: 3 days
Sponsored by: iXsystems, Inc.
ctld(8) child processes to indicate initiator address and name in
their titles, similar to what iscsid(8) child processes do.
PR: 181352
Differential Revision: https://reviews.freebsd.org/D2363
Reviewed by: rwatson@, mjg@
MFC after: 1 month
Sponsored by: The FreeBSD Foundation
