RE: qt multi- and broadcast (was Re: dhcpcd not working in simh-vax with xq0:nat networking)

[Mark Pizzolato - Info Comm <Mark%infocomm.com@localhost>]

On Sunday, December 12, 2021 at 12:54 PM, Rhialto wrote:
> On Sun 12 Dec 2021 at 20:19:42 +0000, Mark Pizzolato - Info Comm wrote:
> > This sounds completely reasonable.  Is there anything in the qt driver
> > which deals with these ioctl functions?  The code which handles that in qt
> > should be common with (or copied from) other drivers which use LANCE
> chips...
> 
> Nope, that's completely missing in the qt driver.
> 
> There are LANCE drivers all over the place, it seems; that makes it a
> bit confusing to find the right parts.
> sys/arch/vax/if/if_le_vsbus.c is a VAX version which defers to
> sys/dev/ic/am7990.c and/or sys/dev/ic/lance.c. Finally in that file
> there is

Sounds confusing.  The logic is also in sImh's sim_ether.C since it 
implements the behavior of the hardware.

> Now here comes my ignorance about hardware:
> Does the DELQA-T mode indeed use a LANCE chip (or just something a bit
> similar)? Does the DELQA-normal mode use it too, or does the card have 2
> chips? (That would be more expensive...) If both modes use it, how can
> they have such different programming models?

Good question.  I'm guessing there is no extra hardware, I think the 
DELQA-T mode just lets the OS driver get a little closer to the chip.  I 
suspect that the rest of the DEQNA emulation in the DELQA-T merely uses 
the LANCE chip in promiscuous mode and provides the working DEQNA
interface behavior in firmware.  As I understand things, the point of the 
smarter mode is to have a rock solid control protocol with minimal need 
for the driver to touch the hardware.  There were problems with 
synchronization issues with the original DEQNA hardware implementation 
of the buffer handling protocol that actually required DEC to replace all 
early versions of the DEQNA in the field with at least new firmware and 
possibly other ECOs.  These were absolutely deployed outside of Digital 
and as I recall they provided an advance swap model for users.

> > QE Broadcast packet reception must be explicitly enabled as mentioned
> > at the end of paragraph three in 3.6.2.4:
> >      The broadcast Ethernet address (all Is) may be optionally enabled.
> 
> Ah yes, I read that differently (probably not as intended), as "you can
> include it if you insist, but it's not needed really".

It was this requirement in DEQNA mode and the fact that VMS provided 
the Multi-cast hash with the broadcast bit set that led me to assume 
broadcast wasn't part of the basic functionality of DELQA-T mode.

- Mark