OpenCores
URL https://opencores.org/ocsvn/or1k/or1k/trunk

Subversion Repositories or1k

[/] [or1k/] [trunk/] [linux/] [linux-2.4/] [net/] [802/] [TODO] - Blame information for rev 1765

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.

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.