You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(1) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Daniel S. <st...@in...> - 2002-01-10 21:50:15
|
mark, is it possible to query the whole primary side, ie. backplane topology (devid,vendor,bars, etc) from the seconday side of a 21554? i've been playing around with the 21554's configuration transaction generation feature for the last 3 hours or so, but not being very successful. may be due to my lack of experience with configuration accesses: say, i'd like to simply generate a type 1 configuration like this: (bus << 16) | (dev << 11) | (fn << 8) | (reg & ~3) | 1 ) would this work? i (believe to) understand how pci bridges forward type 1 cycles to subordinate buses, checking primary/secondary/subordinat number, finally converting them to type 0, fine. however, i'm asking because i'm not sure whether e.g. the opposite direction, i.e. backplane-to-lower-busnr works. right now, a'll i'm reading are tons of 0xFFF..'s :) so is this simply not possible or am i just not getting the trick? i thought i could use this information in order to optimise upstream memory mappings for the drawbridge driver throgh simply reading bar contents. besides, in order to run SNs on an embedded bridge, the discovery stuff would need such a feature anyway. ideally, i would be able to generate an image of the whole shared bus topology. regards, dns -- __________________________________________________________________ mailto: st...@in... |
From: Mark H. <mh...@mv...> - 2001-12-13 00:00:28
|
Daniel Stodden wrote: > > hi mark et al. > > On Wed, 2001-12-12 at 16:42, Daniel Stodden wrote: > > > You are not confused at all. You perfectly understand the difficulties > > of using an out-of-band interrupt in 2.14. The committee pondered this > > at length. The choice was an awkward ISR implementation, an ad hoc > > driver for each class of 2.14 hardware that potentially would interfer > > with other uses of the same hardware node, or a prohibition of > > out-of-band interrupts. We chose awkward. Just how awkward depends on > > the rest of the hardware implementation. If the hardware funnels many > > interrupts through a particular interrupt port, then locating the > > initiator node may take some time, although the implementation on the SN > > can mitigate this by limiting the number of outstanding connection > > request that it accepts. And, you are correct, it is possible to lose > > the use of the interrupt system completely if the PN messes up the > > management info. Of course, the PN can normally just scribble all of > > the SN's memory to much more spectacular effect 8-). I suppose we could > > have passed some more information in the initiator CCB - for example, we > > might say that the local management means are filled out with the > > management means that would be given if the responder were to ask for a > > bus interrupt. > > grmpf. fine, i've had a proposal exactly like this in mind while i wrote > the original email. > guess i should write more extensive problem descriptions or carsten will > put _your_ name on my thesis paper. > > This would probably entail an additional phase to the > > connection process to excahnge the speculative management means followed > > by the actual management means. I will keep that in mind if we get to a > > second revision of the spec. > > > > SNs can avoid this problem by using memory polled alerts or by having > > hardware which allows inband interrupts. > > well, without hardware support, at least the SAM ends up > polled on system host PNs. definitely -- unless above management > extension would become part of the next revision. Yeah, this is why I got rid of the SNs SAM - if you have an early draft you'll see that the original RP was for the SN to put its SAM into the RL, and then have the PNs SAM jam the SN - without interrupt support this was very ugly. But if one archtects the system to propagate PNs on the same hardware node as the SN, then you get back to that problem. Many hardwares that appear at first glance not to have an in-band interrupt mechansim actually do - most up systems that have APIC or MPIC interrupt models have the capability of using a PCI write to one of the IP registers to generate an interrupt. I don't now know if that capability is lost in mp systems or not. > > > As for explaining it, well, the spec is already much more expository > > than normal for such specifications. We needed to leave some material > > for your thesis! To say nothing of my consulting business. > > i agree. on the other hand, there are already enough "sidenotes" in > being actually more precise than one might expect. We were besieged for additional explanations during the ballot process. Had it been left to me, I'd have said - oh, you don't understand the subtle implications, buy my book, or read DNS's thesis 8-) However, we got what we got, and only about a year too late. > > i partially find this pretty disturbing. after all, the specification > has been built around PICMG2.x, while leaving even the most basic > property -- host vs. peripheral -- more or less undiscussed. > from that standpoint, you guys should then rather have tried to avoid > terms like "CompactPCI" or even "PCI" in general... :) Ah, but then PICMG probably wouldn't have sponsored the work. > > > Some hints for the implementation of such an ISR - > > The SN may know generally which slots have outstanding requests, and > > hence can limit the potential interrupt routes/sources that need to > > execute the "speculative" isr code. > > > > Using the flush before alert property ensures that the CCB will have a > > state change prior to the arrival of the actual interrupt. This makes > > the search for potential interrupt sources relatively quick, especially > > if the number of outstanding requests has been limited by the SN. > > > > The good news is that this situation is transient, and the SN knows > > whether it needs to perform the additional search or not, based upon > > whether the SN has outstanding connection responses. The problem is > > that there needs to be a sort of general interrupt handler trailer that > > gets conditionally called if the interrupt is not from any known > > source. Perhaps the isr routine can be added to the line where the > > interrupt will occur as needed, and generally not be part of the isr > > chain when not needed. > > > > That is - there is a general_214_search_for_new_interrupt_source routine > > that is registerd as an isr for any line on which a bus 214 interrupt > > might occur. This registration is done as part of the connection > > response prior to entering responder step 4. Then, an unacknowledge > > interrupt on that line will enter the general search handler. There > > will be a limited number of potential 214 sources for that interrupt, > > which the general handler will search. If it finds new management, it > > will set that up and register a new handler, and if there are no more > > pending responses, remove itself from the isr chain. A bit tricky, > > perhaps, but not a whole lot of overhead, and not intrusive to the rest > > of the interrupt system. Just watch the SMP stuff. > > (this last sentence i did not understand) I'll explain below - > > Note that the > > general handler never acks the interrupt, but rather adds the real > > interrupt handler to the list to actually perform the ack after the > > general handler returns. > > neat idea. especially since it would allow to shift the whole 214 irq > dispatch chain over to the interrupt system without need to keep > separate (connection-oriented) queues in a driver. > > however, for a few subtle reasons, it just won't work :P > i don't know about other operating systems, but the linux interrupt > system ist just not prepared to mess around with the isr chains > from within irq context. > the expectations for conventional device drivers are simple: > - probe for the device > - set it up > - register the interrupt handler > - run for a week, the unregister the handler on driver shutdown. > and do that in process context, e.g. insmod/rmmod. > for 99.9% of all possible hardware this is perfectly o.k. > for 2.14 obviously not :) > > that's what the kernel folks expect to happen, and as a result, > request_irq() is doing GFP_KERNEL memory allocations for it's irqaction > descriptor and therefore will crash when called from a bottom half, let > alone from another isr. > free_irq will hang if you try to release the line from the isr itself. Yeah, I don't think that I would have tried to call the normal request_irq and free_irq entries to accomplish my devious puposes. I haven't actually looked into what is needed, but most likey one would be required to play directly with the actual list structures that maintain the interrupt mappings. This might indeed be archtecture dependent. And, if one were to do so, the necessary locking, etc would be needed to keep the other processors out of the lists while they were being manipulated. The source of my SMP remarks. If you aren't willing to go so far as to seriously hack the interrupt structures, then an additional level of interrupt handler can be used to take potential 214 interrupts, and do a sub-dispatch to the ultimate destination handler. Then the tables that describe that dispatch are contained within the single isr, and may be modified by the front end to the dispatcher as needed. This, of course, looks like a single 214 interrupt handler (which probably has to be registered on multiple irqs) to the system. Then various connection contexts register or request interrupt connections as the connections occur. Some of the early designs I played with contemplated that sort of architecture. It's a lot like any other peripheral with limited resources managed and assigned as needed by the resource driver. > > look into arch/i386/kernel/irq.c. in smp builds, free_irq will block > if called from the isr it's going to unregister (is that what you meant > with "watch smp" above?) > so switching isrs directly from within is simply not possible. > at least not without just rewriting the interrupt system of any > architecture we are going to run on B) or adding some interfaces! > > getting process context is not too much of a problem during "normal" > operations. the mcdev interface has been changed in the meanwhile to > allow for a connect() operation, with the very first bus reference (i.e. > RL or SAM) as a parameter. while the connection setup state machines are > still assuming to run from bottom halves, calls to connect() are run > from keventd. this allows the host device to figure out which device the > address refers to and register an isr on the first connection made. > nowadays, i'm thinking whether it would be a better idea to create plain > kernel threads for connection setup, but right now it's just step4 which > gives me a headache. > > fwiw, as far as i can tell from here, 2.14 bus interrupt dispatch will > end up with chains maintained by the respective device driver. Yes, as mentioned above. I should probably read to the end, so as not to influence Carsten too much. Really Carsten, all I did was throw stuff from a very high altitude. > > i've mostly been asking in order to make sure not to misunderstand > things. obviously i didn't. good to know. thanks so far :) > > btw, the 21554 code should be functional (assuming i didn't mess up cvs > contents over the last few days). if you find the time and interest to > try it out let me know. there's still no discovery support and not much > comments in the tree, so i would write a short howto about > "howto-get-it-going" again. I wish I could be more optimistic, but my work commitments are not currently centered on 214, although we will probably move to it if you get something working well. In fact, I'm off to hack some IO_APIC code to accommodate some recent Intel hardware "innovations". > it's now about three month since my last preview release. waaay too much > time. should have done so with the drawbridge drivers. maybe even > before. i thought the hostboard stuff would turn out to be much simpler. > funny :) Usually the way it turns out. Keep up the good work. Mark Huth > > thanks, > dns > > -- > __________________________________________________________________ > mailto: st...@in... > > _______________________________________________ > mcnet4l-devel mailing list > mcn...@li... > https://lists.sourceforge.net/lists/listinfo/mcnet4l-devel |
From: Daniel S. <st...@in...> - 2001-12-12 20:41:02
|
hi mark et al. On Wed, 2001-12-12 at 16:42, Daniel Stodden wrote: > You are not confused at all. You perfectly understand the difficulties > of using an out-of-band interrupt in 2.14. The committee pondered this > at length. The choice was an awkward ISR implementation, an ad hoc > driver for each class of 2.14 hardware that potentially would interfer > with other uses of the same hardware node, or a prohibition of > out-of-band interrupts. We chose awkward. Just how awkward depends on > the rest of the hardware implementation. If the hardware funnels many > interrupts through a particular interrupt port, then locating the > initiator node may take some time, although the implementation on the SN > can mitigate this by limiting the number of outstanding connection > request that it accepts. And, you are correct, it is possible to lose > the use of the interrupt system completely if the PN messes up the > management info. Of course, the PN can normally just scribble all of > the SN's memory to much more spectacular effect 8-). I suppose we could > have passed some more information in the initiator CCB - for example, we > might say that the local management means are filled out with the > management means that would be given if the responder were to ask for a > bus interrupt. grmpf. fine, i've had a proposal exactly like this in mind while i wrote the original email. guess i should write more extensive problem descriptions or carsten will put _your_ name on my thesis paper. This would probably entail an additional phase to the > connection process to excahnge the speculative management means followed > by the actual management means. I will keep that in mind if we get to a > second revision of the spec. > > SNs can avoid this problem by using memory polled alerts or by having > hardware which allows inband interrupts. well, without hardware support, at least the SAM ends up polled on system host PNs. definitely -- unless above management extension would become part of the next revision. > As for explaining it, well, the spec is already much more expository > than normal for such specifications. We needed to leave some material > for your thesis! To say nothing of my consulting business. i agree. on the other hand, there are already enough "sidenotes" in being actually more precise than one might expect. i partially find this pretty disturbing. after all, the specification has been built around PICMG2.x, while leaving even the most basic property -- host vs. peripheral -- more or less undiscussed. from that standpoint, you guys should then rather have tried to avoid terms like "CompactPCI" or even "PCI" in general... :) > Some hints for the implementation of such an ISR - > The SN may know generally which slots have outstanding requests, and > hence can limit the potential interrupt routes/sources that need to > execute the "speculative" isr code. > > Using the flush before alert property ensures that the CCB will have a > state change prior to the arrival of the actual interrupt. This makes > the search for potential interrupt sources relatively quick, especially > if the number of outstanding requests has been limited by the SN. > > The good news is that this situation is transient, and the SN knows > whether it needs to perform the additional search or not, based upon > whether the SN has outstanding connection responses. The problem is > that there needs to be a sort of general interrupt handler trailer that > gets conditionally called if the interrupt is not from any known > source. Perhaps the isr routine can be added to the line where the > interrupt will occur as needed, and generally not be part of the isr > chain when not needed. > > That is - there is a general_214_search_for_new_interrupt_source routine > that is registerd as an isr for any line on which a bus 214 interrupt > might occur. This registration is done as part of the connection > response prior to entering responder step 4. Then, an unacknowledge > interrupt on that line will enter the general search handler. There > will be a limited number of potential 214 sources for that interrupt, > which the general handler will search. If it finds new management, it > will set that up and register a new handler, and if there are no more > pending responses, remove itself from the isr chain. A bit tricky, > perhaps, but not a whole lot of overhead, and not intrusive to the rest > of the interrupt system. Just watch the SMP stuff. (this last sentence i did not understand) Note that the > general handler never acks the interrupt, but rather adds the real > interrupt handler to the list to actually perform the ack after the > general handler returns. neat idea. especially since it would allow to shift the whole 214 irq dispatch chain over to the interrupt system without need to keep separate (connection-oriented) queues in a driver. however, for a few subtle reasons, it just won't work :P i don't know about other operating systems, but the linux interrupt system ist just not prepared to mess around with the isr chains from within irq context. the expectations for conventional device drivers are simple: - probe for the device - set it up - register the interrupt handler - run for a week, the unregister the handler on driver shutdown. and do that in process context, e.g. insmod/rmmod. for 99.9% of all possible hardware this is perfectly o.k. for 2.14 obviously not :) that's what the kernel folks expect to happen, and as a result, request_irq() is doing GFP_KERNEL memory allocations for it's irqaction descriptor and therefore will crash when called from a bottom half, let alone from another isr. free_irq will hang if you try to release the line from the isr itself. look into arch/i386/kernel/irq.c. in smp builds, free_irq will block if called from the isr it's going to unregister (is that what you meant with "watch smp" above?) so switching isrs directly from within is simply not possible. at least not without just rewriting the interrupt system of any architecture we are going to run on B) getting process context is not too much of a problem during "normal" operations. the mcdev interface has been changed in the meanwhile to allow for a connect() operation, with the very first bus reference (i.e. RL or SAM) as a parameter. while the connection setup state machines are still assuming to run from bottom halves, calls to connect() are run from keventd. this allows the host device to figure out which device the address refers to and register an isr on the first connection made. nowadays, i'm thinking whether it would be a better idea to create plain kernel threads for connection setup, but right now it's just step4 which gives me a headache. fwiw, as far as i can tell from here, 2.14 bus interrupt dispatch will end up with chains maintained by the respective device driver. i've mostly been asking in order to make sure not to misunderstand things. obviously i didn't. good to know. thanks so far :) btw, the 21554 code should be functional (assuming i didn't mess up cvs contents over the last few days). if you find the time and interest to try it out let me know. there's still no discovery support and not much comments in the tree, so i would write a short howto about "howto-get-it-going" again. it's now about three month since my last preview release. waaay too much time. should have done so with the drawbridge drivers. maybe even before. i thought the hostboard stuff would turn out to be much simpler. funny :) thanks, dns -- __________________________________________________________________ mailto: st...@in... |
From: Mark H. <mh...@mv...> - 2001-12-11 21:04:48
|
Daniel Stodden wrote: > > mark, > > i'm close to finishing 2.14 device drivers for both > system host boards as well as 21554 based peripherals. > > regarding the host device, i think i've stumbled over > a general problem with the connection setup scheme, > related to out-of-band control alert managements on the receiver side. > > i just did not notice this before, since all the in-band > alerts, e.g. 21554 doorbell interrupts, on peripherals usually do fine > without management descriptors provided by the remote side. > > consider a peripheral (21554) initiating a connection to a > node residing on the system host: > > the initiator would deliver alert descriptors based on 21554 doorbell > interrupts. the responder on the system host would request bus > interrupts. here, the responder needs to rely completely on management > descriptors delivered by the initiator. > > the weirdness starts in initiator step4/responder step4: > here, the responder gets an interrupt from a device it effectively has > not yet seen managements for -- the managements are provded within the > same step in which the interrupt occurs. > so a driver would have to > - parse the managements > - apply the identification mechanism. see if it succeeds. > - apply the clear means. > > all this - basically the whole "responder step4" procedure - will need > to take place directly within the interrupt handling routine. not > impossible, but pretty much work for an irq service, i think. > > interrupts need to be assumed as shared with other devices (both > mcdevices as well as non-mc). so, this has to happen based on an > _assumption_ the interrupt stems from a respective connection. > > if the remote side failed to deliver proper management mechanisms, the > whole responding system gets more or less trashed. no way to clear the > interrupt execept disabling the entire irq line. > > i don't really feel comfortable with this scheme. > has the 2.14 committee been aware of this? maybe the spec should note > some of the implications regarding dependencies on alert managements? > > confused again :), > dns > > -- > __________________________________________________________________ > mailto: st...@in... > > _______________________________________________ > mcnet4l-devel mailing list > mcn...@li... > https://lists.sourceforge.net/lists/listinfo/mcnet4l-devel Daniel, You are not confused at all. You perfectly understand the difficulties of using an out-of-band interrupt in 2.14. The committee pondered this at length. The choice was an awkward ISR implementation, an ad hoc driver for each class of 2.14 hardware that potentially would interfer with other uses of the same hardware node, or a prohibition of out-of-band interrupts. We chose awkward. Just how awkward depends on the rest of the hardware implementation. If the hardware funnels many interrupts through a particular interrupt port, then locating the initiator node may take some time, although the implementation on the SN can mitigate this by limiting the number of outstanding connection request that it accepts. And, you are correct, it is possible to lose the use of the interrupt system completely if the PN messes up the management info. Of course, the PN can normally just scribble all of the SN's memory to much more spectacular effect 8-). I suppose we could have passed some more information in the initiator CCB - for example, we might say that the local management means are filled out with the management means that would be given if the responder were to ask for a bus interrupt. This would probably entail an additional phase to the connection process to excahnge the speculative management means followed by the actual management means. I will keep that in mind if we get to a second revision of the spec. SNs can avoid this problem by using memory polled alerts or by having hardware which allows inband interrupts. As for explaining it, well, the spec is already much more expository than normal for such specifications. We needed to leave some material for your thesis! To say nothing of my consulting business. Some hints for the implementation of such an ISR - The SN may know generally which slots have outstanding requests, and hence can limit the potential interrupt routes/sources that need to execute the "speculative" isr code. Using the flush before alert property ensures that the CCB will have a state change prior to the arrival of the actual interrupt. This makes the search for potential interrupt sources relatively quick, especially if the number of outstanding requests has been limited by the SN. The good news is that this situation is transient, and the SN knows whether it needs to perform the additional search or not, based upon whether the SN has outstanding connection responses. The problem is that there needs to be a sort of general interrupt handler trailer that gets conditionally called if the interrupt is not from any known source. Perhaps the isr routine can be added to the line where the interrupt will occur as needed, and generally not be part of the isr chain when not needed. That is - there is a general_214_search_for_new_interrupt_source routine that is registerd as an isr for any line on which a bus 214 interrupt might occur. This registration is done as part of the connection response prior to entering responder step 4. Then, an unacknowledge interrupt on that line will enter the general search handler. There will be a limited number of potential 214 sources for that interrupt, which the general handler will search. If it finds new management, it will set that up and register a new handler, and if there are no more pending responses, remove itself from the isr chain. A bit tricky, perhaps, but not a whole lot of overhead, and not intrusive to the rest of the interrupt system. Just watch the SMP stuff. Note that the general handler never acks the interrupt, but rather adds the real interrupt handler to the list to actually perform the ack after the general handler returns. Sorry for the back of the table cloth design, but you get the point. Regards, Mark Huth MontaVista Software |
From: Daniel S. <st...@in...> - 2001-12-10 18:03:45
|
mark, i'm close to finishing 2.14 device drivers for both system host boards as well as 21554 based peripherals. regarding the host device, i think i've stumbled over a general problem with the connection setup scheme, related to out-of-band control alert managements on the receiver side. i just did not notice this before, since all the in-band alerts, e.g. 21554 doorbell interrupts, on peripherals usually do fine without management descriptors provided by the remote side. consider a peripheral (21554) initiating a connection to a node residing on the system host: the initiator would deliver alert descriptors based on 21554 doorbell interrupts. the responder on the system host would request bus interrupts. here, the responder needs to rely completely on management descriptors delivered by the initiator. the weirdness starts in initiator step4/responder step4: here, the responder gets an interrupt from a device it effectively has not yet seen managements for -- the managements are provded within the same step in which the interrupt occurs. so a driver would have to - parse the managements - apply the identification mechanism. see if it succeeds. - apply the clear means. all this - basically the whole "responder step4" procedure - will need to take place directly within the interrupt handling routine. not impossible, but pretty much work for an irq service, i think. interrupts need to be assumed as shared with other devices (both mcdevices as well as non-mc). so, this has to happen based on an _assumption_ the interrupt stems from a respective connection. if the remote side failed to deliver proper management mechanisms, the whole responding system gets more or less trashed. no way to clear the interrupt execept disabling the entire irq line. i don't really feel comfortable with this scheme. has the 2.14 committee been aware of this? maybe the spec should note some of the implications regarding dependencies on alert managements? confused again :), dns -- __________________________________________________________________ mailto: st...@in... |
From: Daniel S. <st...@in...> - 2001-11-12 12:57:01
|
On Mon, 2001-11-12 at 02:56, Bernd Eckenfels wrote: > Hello Daniel, > > > this adds support for 64-bit EUI hardware addressing. > > I have commited the patch. Can you send me a reference, where those Hardware > identifiers are actually used? > > Greetings > Bernd thanx a lot. i'd thought it got ignored :) ARPHRD_EUI64=27 is assigned at http://www.iana.org/assignments/arp-parameters as you're probably aware of, it's actually not a hardware type by its own, but the applied addressing model: http://standards.ieee.org/regauth/oui/tutorials/ i'm currently developing a prototype for a link layer protocol specification (PICMG2.14) for embedded devices communicating in shared memory on CompactPCI backplanes, which makes use of above 64-bit addressing. The specification is available at: http://www.picmg.org/specdirectory.stm The project is still pretty alpha stage, available at http://sourceforge.net/projects/mcnet4l since iana seems to have no problem assigning addressing identifiers to arp hardware headers (as opposed to protocol identifiers), i'd thought it should be ok for net-tools to recognize this type. I currently have no directly assigned number available for PICMG2.14, and there generally seems to be no other supported id for reading/configuring 64-bit hardware addresses. best regards, dns |
From: Daniel S. <st...@in...> - 2001-10-05 00:18:01
|
hi mark. i must admit i'm having serious trouble with the type assignments on packet headers. i originally expected standard EtherType assignments, but according to DR1.0 appendix E i was wrong (though i'm sure that's what people originally had in mind). 1. first issue: what is a ``raw 2.14 packet''? i know what a raw _socket_ is, but raw packets? is this meant to support the mcni? then the mcni should have done without user provided packet headers, but rather provide a target addresses as parameters. it is interfering with the protocol stack anyways. 2. encapsulating IP is fine, but how do i now get ARP on wire? through ethernet frames? (nonsensical. that would completely mess up the concepts of encapsulation). confused, daniel -- ___________________________________________________________________________ mailto:st...@in... |
From: Mark H. <mar...@mv...> - 2001-09-19 23:28:32
|
Daniel Stodden wrote: > Mark Huth <mar...@mv...> writes: > > > Hi, Daniel, et al.. > > > > We fixed the byte ordering, although it would be incorrect to refer to it as > > big endian or little endian, since the moniker is a string of octets, and not a > > number. > > i know. but according to the definition of company_id and oui, eui > (not mac) addresses _are_ binary numbers (that's the only difference > between oui and company_id). in fact, that's the only definition which > distinguishes mac-48 from eui-48 -- apart from the application > statement. > > and that's where describing a 2.14 moniker as eui-48 instead of mac-48 > actually seems right. in my understanding of 2.14 monikers, > interpretation as a binary number (and in-memory value) instead of an > octet string has been perfectly intentional ( "a moniker is a 64-bit > value.." ). otherwise the original ordering would never have made any > sense at all. Could be the spec is not consistent. The drawing shows it as an array of bytes. Otherwise the 64-bit value would just be a 64-bit number, like addresses, for example. It is really intended as an extension of the MAC address concept. The EUI description was, unfortunately, not adequately reviewed. Mark Huth > > > according to the ieee faq[1], the term "company_id" stems from IEEE > Std 1212-1991, IEEE Standard Control and Status Register (CSR) > Architecture. > to me this looks like EUI was originally defined with in-memory > locations in mind, in contrast to 802's MAC being a sequence with a > focus of bitwise serialization. > > regards, > dns > > -- > ___________________________________________________________________________ > mailto:st...@in... > > _______________________________________________ > mcnet4l-devel mailing list > mcn...@li... > http://lists.sourceforge.net/lists/listinfo/mcnet4l-devel |
From: Daniel S. <st...@in...> - 2001-09-18 21:14:47
|
Mark Huth <mar...@mv...> writes: > Hi, Daniel, et al.. > > We fixed the byte ordering, although it would be incorrect to refer to it as > big endian or little endian, since the moniker is a string of octets, and not a > number. i know. but according to the definition of company_id and oui, eui (not mac) addresses _are_ binary numbers (that's the only difference between oui and company_id). in fact, that's the only definition which distinguishes mac-48 from eui-48 -- apart from the application statement. and that's where describing a 2.14 moniker as eui-48 instead of mac-48 actually seems right. in my understanding of 2.14 monikers, interpretation as a binary number (and in-memory value) instead of an octet string has been perfectly intentional ( "a moniker is a 64-bit value.." ). otherwise the original ordering would never have made any sense at all. according to the ieee faq[1], the term "company_id" stems from IEEE Std 1212-1991, IEEE Standard Control and Status Register (CSR) Architecture. to me this looks like EUI was originally defined with in-memory locations in mind, in contrast to 802's MAC being a sequence with a focus of bitwise serialization. regards, dns -- ___________________________________________________________________________ mailto:st...@in... |
From: Mark H. <mar...@mv...> - 2001-09-18 18:27:26
|
Hi, Daniel, et al.. We fixed the byte ordering, although it would be incorrect to refer to it as big endian or little endian, since the moniker is a string of octets, and not a number. I read the info at http://standards.ieee.org/regauth/oui/tutorials/EUI64.html and you are correct, the encapsulation in the spec is incorrect, and, in fact, violates IEEE guidelines for encapsulation. While it works as is, the IEEE holds trademark and copyrights to the use of this forma, and we are not in compliance. Sean, how do we want to handle an erratum of this type? Can we publish a notice on the PICMG website? The change is that the MAC-48 to EUI-64 encapsulation uses FFFF rather than FFFE as the extension sequence. While the extension from EUI-48 to EUI-64 given in the 2.14 spec is correct, the value we need to extend is a MAC-48. An EUI-48 is not a hardware class instance, but rather the class itself. But the MAC-48 is the instance address, which is what we need to extend. Mark Huth Daniel Stodden wrote: > hi "all" :) > > first of all, i noticed yesterday that somewhere between D0.64 and > D1.0 the moniker byte order has been reverted to true EUI-64 byte > ordering (big endian) as opposed to the rest of binary number formats > being le. > > whoever proposed this: thank you, good idea (no kidding). makes my > day. > > second, an issue regarding 48/64-bit conversions: > > the following is taken from > http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html > (i must admit i actually never read that page before) > > * MAC-48: A 48-bit identifier used to address hardware interfaces > within existing 802 based networking applications > * EUI-48: A 48-bit identifier used to identify a design instance, as > opposed to a hardware instance. Examples include software interface > standards (such as VGA) or the model number for a product. > * EUI-64: A 64-bit identifier used to identify each hardware instance > of a product, regardless of application, such as wireless devices > and computerized toasters. > > while the difference between MAC-48 and EUI-48 is pretty zero > regarding the resulting addressing scheme, the above statement makes > 2.14 appear to me rather as a MAC-48 application than EUI-48. > Ok, the question whether 2.14 is 802 based is definition dependant, > but a moniker is definitely not a design instance as defined above. > > Why I care? 48-bit encapsulation: > > ccccccFFFEeeeeee16 (an EUI-48 extension) > > ccccccFFFFeeeeee16 (a MAC-48 extension) > > from this standpoint the encapsulation scheme described in 2.14 > chapter 3.1, defining a fill sequence of ff:fe would be wrong. > > assuming to be right here: i'm not sure about the implications. As > long as everybody is coding along the picmg spec and does not look > into ieee documents, this certainly does not break interoperability on > the backplane. any 'theoretical' danger when bridging into 802.x LANs > or stuff like that? > > regards, > dns > > -- > ___________________________________________________________________________ > mailto:st...@in... > > _______________________________________________ > mcnet4l-devel mailing list > mcn...@li... > http://lists.sourceforge.net/lists/listinfo/mcnet4l-devel |
From: Daniel S. <st...@in...> - 2001-09-18 13:22:38
|
hi "all" :) first of all, i noticed yesterday that somewhere between D0.64 and D1.0 the moniker byte order has been reverted to true EUI-64 byte ordering (big endian) as opposed to the rest of binary number formats being le. whoever proposed this: thank you, good idea (no kidding). makes my day. second, an issue regarding 48/64-bit conversions: the following is taken from http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html (i must admit i actually never read that page before) * MAC-48: A 48-bit identifier used to address hardware interfaces within existing 802 based networking applications * EUI-48: A 48-bit identifier used to identify a design instance, as opposed to a hardware instance. Examples include software interface standards (such as VGA) or the model number for a product. * EUI-64: A 64-bit identifier used to identify each hardware instance of a product, regardless of application, such as wireless devices and computerized toasters. while the difference between MAC-48 and EUI-48 is pretty zero regarding the resulting addressing scheme, the above statement makes 2.14 appear to me rather as a MAC-48 application than EUI-48. Ok, the question whether 2.14 is 802 based is definition dependant, but a moniker is definitely not a design instance as defined above. Why I care? 48-bit encapsulation: ccccccFFFEeeeeee16 (an EUI-48 extension) ccccccFFFFeeeeee16 (a MAC-48 extension) from this standpoint the encapsulation scheme described in 2.14 chapter 3.1, defining a fill sequence of ff:fe would be wrong. assuming to be right here: i'm not sure about the implications. As long as everybody is coding along the picmg spec and does not look into ieee documents, this certainly does not break interoperability on the backplane. any 'theoretical' danger when bridging into 802.x LANs or stuff like that? regards, dns -- ___________________________________________________________________________ mailto:st...@in... |
From: Daniel S. <st...@in...> - 2001-09-03 20:16:27
|
as the subject says. -- ___________________________________________________________________________ mailto:st...@in... |