Thread: 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 |
From: Andreas B. <and...@mu...> - 2000-04-03 00:58:09
|
You are apparantly not using the current patch. Between this and the previous the byte order policy changed, now bytes appear on the bus as they are ordered in RAM (i.e. no hardware byte swapping is done anymore on little endian -- except for the header, but this is an internal issue). User programs and highlevel drivers must now swap the data on their own, which resolves some messy problems (with the data payload not being a quadlet sequence and therefore being swapped wrongly by the hardware). This also solves the length problem and now arbitrary lengths for block requests are allowed (the subsystem pads zero bytes automatically). -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |
From: Manfred W. <e95...@st...> - 2000-04-04 17:26:35
|
Andreas Bombe wrote: > ... the byte order policy changed, now bytes appear on the bus as > they are ordered in RAM (i.e. no hardware byte swapping is done > anymore on little endian -- except for the header, but this is an > internal issue). That is not completely true. Since the header of iso packets is stored in the first quadlet of the buffer which is handed over to iso_handler_t, it is not an internal issue of the driver, because also user space applications get access to it. BTW: It took me quite a while to find out, that the first quadlet of this buffer is the 1394-header (stored little endian), then the header-crc is missing, and then the rest (the data) of the packet follows (stored big endian). Of course it makes sense that this header is handed over to the iso handler (because it provides a means to find out, if the packet has a CIP header), but it could be considered if it makes more sense to change its byte order (so that _everything_ is big endian) or to introduce new arguments for the handler (expecially Tag and perhaps Sy) and remove the header from the buffer. Manfred Weihs |
From: Rodney R. <re...@de...> - 2000-04-04 22:24:15
|
What Manfred asserts stands to reason, in order for hardware to handle headers, and for future extensibility, the hardware has to be able to parse the header. Thus the big/little endian issue doesn't stand into it: the type of the header is known, it is a bit vector, of fixed variable lengths, whose image, however, requires transposition on the quadlet boundry in little endian RAM but not in big endian RAM. The data field however is a different story its type is not known to the hardware and in little endian the DMA R/W order is reversed over big endian. In my previous discourse, I was not talking about making the ordinal value of a quadlet in memory the same in both boxes, that's an assumption of the type of data contained in the field. I was talking about the definition of binary compatibility here: the order of the bytes are addressed be the same in any box. I will expand further on the example. In order to preserve binary compatibility hardware little endian must(optimally) transpose the byte stream in situ because the DMA R/W order is different during each of these instances depending on DMA transfer size: quadlet, or doublet, or singlet. Examine the following given the message is "12345": LilI BigI Address(8)-> 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 case byte(8:8) RAM-PORT r/w 1 2 3 4 5 x x x 1 2 3 4 5 x x x STREAM(X = swap) 1 2 3 4 5 x x x 1 2 3 4 5 x x x case quadlet(32:8) RAM-PORT r/w 4321 xxx5 1234 5xxx STREAM(no swap) 4 3 2 1 x x x 5 1 2 3 4 5 x x x STREAM(swap) 1 2 3 4 5 x x x 4 3 2 1 x x x 5 From this is should be apparent that, unless hardware swaps, in order for binary compatability to occur, a little endian box must swap the bytes in RAM if DMA is set to do quadlet(32:8) transfers but it does not matter if DMA is set to do byte(8:8) transfers. It also should be noted this has no consequence under some circumstances. A hard drive for instance would save and return the data in the same order regardless if bytes are swapped or not(if the parameters don't change). But, box-to-box communication requires a definition of binary compatability. A few advisories exists here once the swaping issue is resolved. First, when transfering quadlets covered in the case of the OHCI spec. Here the type of the data field is known(a possible assumption, if it be agree that) and the ordinal value is preserved when swap is set and the software does a second swap. Second, when writing data that came in from the data field bound for the header field of another packet, such as the address. Further, this brings up a new issue, if true hardware independence is to be achieved in the interface, some read-only properties of the device(low-level) layer must be known to the service(high-level) layer. Data polarity (big/little endian) is one, another is the GUID of the card. The case of the polarity property is that hardware may implement swapping but some cards may not(see the previous advisory). The case for the GUID is that the ordinal value must be preserved if not it looses its uniqueness and the method of aquisition of this value is hardware dependent. Rodney Rhoton Manfred Weihs wrote: >That is not completely true. Since the header of iso packets is stored >in the first quadlet of the buffer which is handed over to >iso_handler_t, it is not an internal issue of the driver, because also >user space applications get access to it. >BTW: It took me quite a while to find out, that the first quadlet of >this buffer is the 1394-header (stored little endian), then the >header-crc is missing, and then the rest (the data) of the packet >follows (stored big endian). Of course it makes sense that this header >is handed over to the iso handler (because it provides a means to find >out, if the packet has a CIP header), but it could be considered if it >makes more sense to change its byte order (so that _everything_ is big >endian) or to introduce new arguments for the handler (expecially Tag >and perhaps Sy) and remove the header from the buffer. Andreas Bombe wrote: > ... the byte order policy changed, now bytes appear on the bus as > they are ordered in RAM (i.e. no hardware byte swapping is done > anymore on little endian -- except for the header, but this is an > internal issue). |
From: Andreas B. <and...@mu...> - 2000-04-04 23:16:18
|
On Tue, Apr 04, 2000 at 07:17:08PM +0200, Manfred Weihs wrote: > Andreas Bombe wrote: > > ... the byte order policy changed, now bytes appear on the bus as > > they are ordered in RAM (i.e. no hardware byte swapping is done > > anymore on little endian -- except for the header, but this is an > > internal issue). > > That is not completely true. Since the header of iso packets is stored > in the first quadlet of the buffer which is handed over to > iso_handler_t, it is not an internal issue of the driver, because also > user space applications get access to it. Yes, making the iso header also big endian in raw1394 might be good for consistency. -- Andreas E. Bombe <and...@mu...> DSA key 0x04880A44 http://home.pages.de/~andreas.bombe/ http://linux1394.sourceforge.net/ |