Additional configuration options for DaynaPort emulation

[akuker]

Info

From Discord user "speakers#7740"

I've been messing with piscsi Daynaport ethernet to write a driver for NetBSD. In particular, this is to provide ethernet on my SE30. The driver is based on the age-old se driver for Cabletron EA41x. I run NetBSD 3.1 on my 68k macs since it's reliable and reasonably fast -- although (amazingly) the latest version (9) will install and run.

I have a functional driver, but I've also needed to modify the piscsi code in two respects. Firstly, the send delay workaround for MacOS needs to be disabled. Secondly, the minimum packet size needs to be raised from 64 to 128 so that small packets - particularly ARPs -- are exchanged correctly. The changes are dynamic and depend on the behavior of the client OS. I can provide a diff.

[akuker]

Note that this needs to be updated on the fly, since the Mac will boot into MacOS first, then switch over to BSD

[speakers-k64]

Here's diffs that enables both MacOS and NetBSD to use the DaynaPort emulation:
bsd.patch

[uweseimet]

@speakers-k64 It may now be possible to make progress on this ticket. For the upcoming bookworm release (also running on bullseye) I removed the strange delay work-around. Testing has shown that it is not needed for the Mac.
Whether the packet size change can be applied depends on how the DaynaPort driver for the Atari deals with it, i.e. whether this driver also works with this patch applied. We can try to find this out once the bookworm release is available.

@mzryz Would you be willing to test this with your Atari?

@benjamink I'm aware that you have already spent a lot of time on #1306, but it would be great if you could also help here. I would like to verify whether the Mac really needs a work-around for the packet size. Most work-arounds in the piscsi code have turned out not to be required and some have even made things worse, so we should verify this.
In case you agree I would modify the existing "testing_daynaport" branch accordingly and would ask you for an additional test with this branch.

[benjamink]

@benjamink I'm aware that you have already spent a lot of time on #1306, but it would be great if you could also help here. I would like to verify whether the Mac really needs a work-around for the packet size. Most work-arounds in the piscsi code have turned out not to be required and some have even made things worse, so we should verify this. In case you agree I would modify the existing "testing_daynaport" branch accordingly and would ask you for an additional test with this branch.

@uweseimet absolutely! Let me know what you need.

[uweseimet]

@benjamink Thank you! As far as I can tell two things have to be tested, and I created a new branch testing_daynaport_2 for this. This branch is identical to issue_1306, which you have tested earlier, except for a work-around I removed. I would like to know whether networking still works for you with this branch.

[benjamink]

@uweseimet commit 0e77ab3fbdad14871d6ff0f02ddc63c935fd6c49 failed.

The Mac boots quickly without getting stuck on the AFP share mount but once the desktop loads the share is not mounted & an error pops up on the screen (I'll attach screenshot in a moment).

piscsi-issue-1088.log

[benjamink]

[uweseimet]

@benjamink OK, thank you. I just reverted the change and now applied a different change in order to test the second work-around regarding the packet size. Please update your testing_daynaport_2 branch and test again. No "make clean" required, just "make".

[benjamink]

@uweseimet commit 5ab222acfe26fb9ab9f342f3ec0413c0d0cac8a3 works

[uweseimet]

@benjamink Once more, thank you for testing. This means that the Mac would be fine with unconditionally setting the packet size to a minumum of 128 bytes.
If this also works for the Atari this value can simply be changed and it will work with all platforms without any platform-specific code.

[benjamink]

No problem. Just let me know if you need me to run any more.

[uweseimet]

@benjamink Not currently, thank you for the offer.

[uweseimet]

@anodynesoftware Just a quick question: Before we spend time on a trial-and-error approach, maybe you know by heart or can check whether your driver is fine with a minimum packet siize of 128 instead of 64 bytes?

[uweseimet]

OK, with some help I have managed to use the daynaport emulation with an Atari. I have just tested transfers with a minimum packet size of 128 bytes and there has not been an obvious issue.

[uweseimet]

Development note: For a work-around like the one suggested the initiator ID has also to be remembered. Otherwise there would be issues with more than one initiator on the same SCSI chain.

[uweseimet]

@speakers-k64 In the latest develop branch the minimum packet size is 128 bytes now. The other change you suggested might also be added, but needs to take the initiator ID into account (see my previous comment).
Can you please test whether the current develop branch works when you remove the DaynaPort delay? Please note that we depend on your feedback for changing this code. Without feedback we cannot test this change and would have to discard this ticket.

[anodynesoftware]

On 8 Nov 2023 at 14:08, Uwe Seimet wrote: @anodynesoftware Just a quick question: Before we spend time on a trial-and-error approach, maybe you know by heart or can check whether your driver is fine with a minimum packet siize of 128 instead of 64 bytes?

Sorry for the delay in responding to this. All the driver cares about is that the encapsulated Ethernet packet size is within the range specified by the Ethernet standard. So if a packet is padded out to 128 bytes rather than 64 it should make no difference. Roger

[uweseimet]

@anodynesoftware Thank you for the feedback. Previous testing has confirmed this (eventually with a lot of help I was able to set up a running network on my TT). For PiSCSI the size has already been increased in the develop branch.

[speakers-k64]

Apologies for the delay .. I needed to acquire another Pi.

I've verified that the development build works with MacOS 7.6 on my SE/30 and that, unmodified, it fails with NetBSD. In addition to the packet size increase, my NetBSD driver also requires no send delay. I'm attaching a revised version of my patch against the develop branch. Note that the NetBSD booter runs under MacOS so that piscsi must dynamically adapt to MacOS running first and then NetBSD gaining control.
develop_diffs.txt

@uweseimet - I don't understand your comment about initiator ID: what hardware configuration would give rise to any issue and how so?

[uweseimet]

@speakers-k64 Thank you for your feedback. Regarding the initiator ID, you need to consider this because there may be more than just one computer in the SCSI chain. I sometimes have a scenario like that, and this is also supported by the SCSI standard. Image your BSD Mac has SCSI ID 7 and is on the same chain as a MacOS Mac with SCSi ID 6. If both use the DaynaPort emulation you have to ensure that there is a delay for initiator ID 6, but not for initiator ID 7.

The correct approach to resolving your issue would IMO be to only have a delay if the Mac driver that requires it is used. Otherwise there should be no delay. BSD does not work with it, the Atari does not need it. This means that having a delay should not be the rule, like now, but should be the exception, because there is only one broken driver that needs it.

I will get back to you regarding a solution later this month.

[speakers-k64]

@speakers-k64 Thank you for your feedback. Regarding the initiator ID, you need to consider this because there may be more than just one computer in the SCSI chain. I sometimes have a scenario like that, and this is also supported by the SCSI standard. Image your BSD Mac has SCSI ID 7 and is on the same chain as a MacOS Mac with SCSi ID 6. If both use the DaynaPort emulation you have to ensure that there is a delay for initiator ID 6, but not for initiator ID 7.

I understand the SCSI general case, but for the specifics of DaynaPort Ethernet over SCSI, more than one initiator was not the intended case. And is it even possible to have Mac with SSCI ID other than 7?

[uweseimet]

I am quite sure that you can configure this for a Mac .With other platforms this is definitely possible, e.g. with regular PCs, Ataris and various workstations.
My goal is not to implement platform-specific solutions or work-arounds when a general solution is possible.