A BUG and ieee1394_transactions.c: FIXME: Lengths not multiple of 4 are not implemented.
Brought to you by:
aeb,
bencollins
From: Rodney R. <re...@de...> - 2000-04-01 21:53:14
|
I have arrived, help me out though, I'm a newcommer to Linux projects and the 1394 spec. I've got 10yrs of C and about 5yrs of C++ and even CS degree I thought I'd never need, my mainstay is client-server. Basically, I'm hot on network communication like the ether-on-1394 solution. I've got several issues to bring up here but first sourceforge.net wouldn't bring up the archive so I don't have any knowledge of what's been discussed so bear with me if something is redundant. I realize alot of you are intrested in the neat new hardware that's available utilizing 1394, but as for me, once you get all that data your going to need inter-processor comunication to render it in your life time :^) First, my build environ is on RH6.0 PII-350 SMP machine known to my subnet as linus.de-signs.net after you know who. I used the previous version of the 1394 project patch and it worked without a hitch on v2.2.13. I did not installed hardware and that pointed out in a minor bug(see next). I also have a PIII-450 SMP on NT called k9.de-signs.net to use for the other end of the wire. Here's how linus goes at boot: ieee1394: registered ohci1394 driver, initializing now ohci1394: looking for Ohci1394 cards ohci1394: no operable Ohci1394 cards found ieee1394: detected 0 ohci1394 adapters ieee1394: 1 host adapter initialized Upon examination of the code the '1' comes from hosts.c::hpsb_register_lowlevel. This function only returns '0' and nothing to indicate success or failure of its dependent, so the count continues. Its not a functional handicap, so I assume this went unnoticed. Second, and more importantly, the issue above is really several issues. The code(and comments) as written selects a quadlet packet or buffer based on size and that's like asking the client for the type. Let's get something straight about just what is binary compatabile interface first. It has always been my opinion that this hardware driver class was nominally responsible for the following issues: 1) transmitting data in binary compatability mode(i.e. stream of bit ordered bytes) 2) Providing either a maximum packet size, implement transparent package splitting/reassembly, or both. 3) Allow partial aquisition of the data in the read buffer(packet peeking), and 4) Implement client package alignment and justification in the hardware holding buffer(DMA). I will cover each of these in turn but the latter is not an issue in the case of OHCI and was added for completeness, however; 802 packets come/go miss-aligned as you may know. The third issue I'm not prepared to discuss here but would like to hear some comments. To go on, having meet these specs, all super layers may then provide behavior according to their specific need. ether-on-1394, for example, would be considered a upper-layer(service) driver utilizing this interface. In order for interoperability to occur on a network where this layer might come from different sources, the interface must match some specifcation at the middle(device independent) layer. In other words, their has to be a way to push a packet through the connection with minimal assumptions and data dependencies. The tree grows as a consequence of the leaves, so to speak. Please refer to following while I address the first issue above: [1(see below)] Sect 5.7;pp45-47, [3] Sect 3.5 and ieee1394_transactions.c To use the example in the comment of the code, given '12345' is the message, in a little endian, then the sequence 1234,5xxx is read into a register from the port(or through DMA), which must reordered in the register so it can be layed down in memory as words 4321,xxx5. If the chronology(i.e. apparent order of the bytes in a quadlet in the channel) is reversed, then no reshuffling has to take place(at least for the data-field), in this case, the message is recieved as 4321,xxx5. It would be optimal to have the hardware preform the actual byte swaps. OHCI provides for this capability with a control bit: HCControl.noByteSwapData which controls only the data field of the packet. (I don't see this used in ohci1394.c/h and have not looked in the other drivers.) Assuming PHY does not swap, and the chronological sequence is big-endian(ibid p47) according to the OHCI specs, therefore, if a little endian machine clears this bit and big endian sets it, no reshuffling will be required on any machine except in the _header_ fields. The resolution of this issue in the middle layers of the driver seems simple: allow odd sized buffers >=0 bytes to be transmitted since there is no harm done by padding the client data package with null bytes when its moved into the kernel memory space if 1394Packet.data_length is set correctly to the unaligned length in the header on write. And, on read, odd bytes will appear in the proper order if 1394Packet.data_length is obtained and returned to the caller as well as the buffer after stripping the header. (Note also that raw1394.c/h also enforces data sizes to be mulitiples of 4 bytes) As to the second issue above, please also refer to [2] below. It would be optimal in terms of performance and code size for future extensions, like ether-on-1394, if packet fragmentation was available and had ioctl parameters to set the internal fragment size. This is the case in the MS design for the middle layer. An example would be a file system where the node allocation structures and cache read look ahead sizes exceeds the maximum packet size of the media but packets still had to contain a sector multiples. Since this is my first examination of this kind of code in Linux I don't know if there exists a trend to implement this at this level or not. 1394 spec allows for this kind of behavior through the address space allocation which is just a tag for the packet. This is also neccessary since out-of-order IO is allowed(yeah, its a box-o-worms). The middle layer driver thus should implement control of this behavior with an additional parameters, either through the address request allocation scheme or directly in the I/O initiation calls with the latter more preferable to the former. The extra parameters would tell the implementation how to enumerate through the address space and where to split a buffer when a client packet is larger than the media allows. It would also enable the linux implementation the most flexibility to match other platforms for host-to-host communication through ether or some other protocol like SCSI or ATAPI. Now back to the ether-on-1394 solution. If the above was implemented(fixed) then a few things would be in order. Either, just transmit 802.3 packets to some pre-agreed address range, or the ARP table must include the address space and software on the nodes would have to be able to exchange this information with one another at some pre-agreed address. The latter method would overcome 64 node limit and get very high bisection bandwidth of the 1394 ether network since routing is directed from the source. Thus the AR table would need to translate from an ip-mask pair to possibly multiple node_id-address_space pairs. Well that's as far as I got today, I'd like to hear some comments. Rodney Refs: [1] ftp://download.intel.com/technology/1394/download/ohci_11.pdf [2] http://www.microsoft.com/ddk/ddkdocs/win2k/default.htm Kernal-Mode Drivers/Design Guide/Part 6 IEEE1394 Drivers [3] http://www.1394ta.org/Download/Technology/Specifications/iicp1.0.pdf |