mcnet4l-devel — Developer Mailing List

[mcnet4l-devel] 21554 configuration access

[Daniel S. <st...@in...>]

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...

Re: [mcnet4l-devel] Re: responder step 4

[Mark H. <mh...@mv...>]

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

[mcnet4l-devel] Re: responder step 4

[Daniel S. <st...@in...>]

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...

Re: [mcnet4l-devel] responder step 4

[Mark H. <mh...@mv...>]

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

[mcnet4l-devel] responder step 4

[Daniel S. <st...@in...>]

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] Re: [PATCH] net-tools: generic eui64

[Daniel S. <st...@in...>]

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

[mcnet4l-devel] protocol encapsulation

[Daniel S. <st...@in...>]

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...

Re: [mcnet4l-devel] eui-48 and moniker conversion.

[Mark H. <mar...@mv...>]

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

Re: [mcnet4l-devel] eui-48 and moniker conversion.

[Daniel S. <st...@in...>]

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...

Re: [mcnet4l-devel] eui-48 and moniker conversion.

[Mark H. <mar...@mv...>]

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

[mcnet4l-devel] eui-48 and moniker conversion.

[Daniel S. <st...@in...>]

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] test 1 2 3

[Daniel S. <st...@in...>]

as the subject says.

-- 
___________________________________________________________________________
 mailto:st...@in...