URL
https://opencores.org/ocsvn/or1k/or1k/trunk
Details |
Compare with Previous |
View Log
Line No. |
Rev |
Author |
Line |
1 |
1275 |
phoenix |
Remaining Problems:
|
2 |
|
|
|
3 |
|
|
1. Serialization of access to variables in the llc structure
|
4 |
|
|
by mac_data_indicate(), timer expired functions, and data_request() .
|
5 |
|
|
There is not serialization of any kind right now.
|
6 |
|
|
While testing, I have not seen any problems that stem from this lack of
|
7 |
|
|
serialization, but it wories me...
|
8 |
|
|
|
9 |
|
|
2. The code is currently able to handle one connection only,
|
10 |
|
|
there is more work in register_cl2llc_client() to make a chain
|
11 |
|
|
of llc structures and in mac_data_indicate() to find back
|
12 |
|
|
the llc structure addressed by an incoming frame.
|
13 |
|
|
According to IEEE, connections are identified by (remote mac + local mac
|
14 |
|
|
+ dsap + ssap). dsap and ssap do not seem important: existing applications
|
15 |
|
|
always use the same dsap/ssap. Its probably sufficient to index on
|
16 |
|
|
the remote mac only.
|
17 |
|
|
|
18 |
|
|
3. There is no test to see if the transmit window is full in data_request()
|
19 |
|
|
as described in the doc p73, "7.5.1 Sending I PDUs" 3th alinea.
|
20 |
|
|
The pdus presented to data_request() could probably go on the
|
21 |
|
|
awaiting-transmit-queue (atq). The real difficulty is coding a test
|
22 |
|
|
to see if the transmit window is used up and to send the queue
|
23 |
|
|
when space in the window becomes available.
|
24 |
|
|
As I have no network layer that can generate a continous flow of pdus it is
|
25 |
|
|
difficult to simulate a remote busy condition and hence to test the code
|
26 |
|
|
to handle it.
|
27 |
|
|
|
28 |
|
|
4. A simple flow control algorithm, steering the size of the transmit
|
29 |
|
|
window would be nice to have.
|
© copyright 1999-2024
OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.