#15 Support packet notification from Link Layer
Background:
Currently applications handle the frequency of polling
the link to see if there are any packets that require
processingif no applications run, there is effectively no
polling.
This may not be good enough for link layers.
e.g. an ethernet link layer may need to constantly poll
ethernet traffic (perhaps enabled through a heartbeat
interupt) to detect if an ARP/DHCP request arrives so
that the link layer can immediately respond to it.
Geoff Weiss proposes an extension to the Marinetti
Link Layer API to assist a polling link layer.
By allowing the link layer to poll, it may receive an IP
packet and will then have to deal with this IP packet.
In order to avoid implementing a queuing mechanism
within the Link Layer for these IP packets
(which Marinetti would obtain when it next polled the
link layer), it is better to notify Marinetti that an IP
packet has been received and request that Marinetti
deal with the IP packet immediately.
Proposal:
To extend the Link Layer API to support a notification
system.
Implementation suggestion:
Add a parameter to the LinkStartup call that notifies the
Link Layer of an entry point that can be used to notify
Marinetti of IP packets that have been received.
Documentation for LinkStartup (IPNotify)
Logged In: YES
user_id=257705
Geoff Weiss provided a document to provide more input on
the suggested implementation, including:
-brief discussion on how Ethernet link layer could use this
-documentation for the LinkStartup call paramater
IPNotifyAddress
-a suggestion for source code changes to the I.IP.S module
to support the implementation
Logged In: YES
user_id=257705
I haven't seen the source to I.IP.S so I'm assuming that the
code that follows Geoff's changes actually processes the
queue.
Additionally, I.DISPATCH (where the LL gets loaded by
Marinetti) will have to have some LL version checking to
determine whether to provide the IPNotify parameter or not.
EXT IPNotify
...
LINKSTARTUP
LDA INTV
CMP #3
BCC :DISPATCH ;Version 3 is not supported
PHL IPNotify
:DISPATCH LDX #LLSTARTUP
BRA LINKDISPATCH
and EQUATES/BUILD.EQU.S needs this change
LLMAXINTVERSION = 3
Logged In: YES
user_id=257705
Geoff Weiss comments on the background information for
why this change would make a difference:
It would be incredibly useful for the ethernet layer to also
support polling. This would allow for faster throughput for
accelerated systems. On a LANceGS, three packets of
maximum MTU can be read in one heartbeat (1.5k for
outgoing packets, 4.5k for incoming packets). If
the GS can process the data fast enough between
heartbeats, polling to the ethernet layer could get more
frames, resulting in faster network access. This will be
extremely important once DHCP is implemented and GS
users put their systems directly on ISDN or cable systems.
There will be alot of broadcast packets which the GS will
need to ignore. A single heartbeat run could read 18 frames
which none may be actually useful for the GS.
Depending on how the ethernet layer code gets optimized,
the heartbeat could end, but more data arrived to the
LANceGS, and another 1/60 seconds would have to wait for
more frame processing. This is when the Marinetti TCPIPPoll
would be extremly useful.
Logged In: YES
user_id=257705
Source code has been theoretically branched to allow this
implementation to proceed at this time.
Geoff has been seeded with TCPIP init v3.1a1 that contains
IPNOTIFY and supports the new LinkStartup API.
Status is pending to remind me that the source code will
need to be merged back into the mainline.
Logged In: YES
user_id=1312539
Originator: NO
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
Logged In: YES
user_id=257705
Originator: YES
Reopening as it should not have been closed.