- Roy,
- Thanks for responding.
- My reply starts with '-'.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
Sebastien Roy
Sent: Thursday, July 20, 2006 1:44 PM
To: james s. edele
Cc: [email protected]
Subject: Re: [networking-discuss] mac_rx bge nemo
James,
On Thu, 2006-07-20 at 13:15 -0700, james s. edele wrote:
> We have software that sits between the IP layer and the NIC
> driver and processes incoming and outgoing packets. It worked
> fine until the new Nemo interface with mac_rx() was implemented
> in Solaris 10.
What about this change broke your software? It would be good to
understand that first. What was the mechanism used prior to Solaris 10?
Was it STREAMS and autopush?
- No it was not streams. We put our hooks in the ill_g_head interface list.
It
- was done in the late 90's and I think they did this for efficiency. It has
been that
- way ever since, since at least Solaris 5.5 days and for all NIC's. Now, I
think based on
- the opensolaris code I have seen, the bge driver calls ip_input() directly
with the
- soft ring feature.
> Now we want to be able configure/register our driver's receive function to
be the
> only receive callback function that mac_rx() calls back from
> the bge driver.
Why do you need to insert your software at that layer? Why not use
either a STREAMS module or the packet filtering hooks that Darren Reed
is working on?
- How do I learn about the packet filtering hooks? Is there an API? Is it
in SOlaris 10?
- Regarding the Streams, it was viewed as inefficient and has worked this
way since the
- late 90's.
>
> To this end some experimental code was created in our driver
> to call mac_open("/dev/bge0",..) in order to get the mac handle
> for bge.
mac_open() is called using the MAC name, not the name of the DLPI node
in the file system. The MAC name for bge0 is "bge0".
- Thanks. That is useful.
> After which we could then do a mac_rx_remove() of
> what's there and then a mac_rx_add() of our receive callback
> function.
That violates the interface between the mac module and other consumers
of that MAC. You'd first have to go find the other mac_rx_handle's
registered for that mac, and there's no safe way to do that. Even if
there were and you were able to remove them, you'd be pulling the rug
out from some other module with unexpected side-effects.
mac_rx_remove() frees the mac_rx_handle, which some other module is
still holding on to. That's a panic waiting to happen.
- we're looking for the way that will avoid panics. If Streams is the way
to
- go, then does bge and other drivers implement a full Streams interface
- in Solaris 10 (and future). I heard a rumor that Sun was moving away
- from Streams for some implementations. Is that true?
>
> mac_open("/dev/bge0"...) is returning EINVAL. It was found that
> the call to ddi_name_to_major() from mac_open() is returning "-1".
> ddi_name_to_major() calls mod_name_to_major() which calls
> find_mbind(). find_mbind() goes thru mb_hashtab[] looking for the
> driver name of "/dev/bge" and doesn't find it.
"bge0" is what you'd want, not "/dev/bge0". Regardless, I think the
overall approach here is going down the wrong path.
>
> Is our above objective doable? That is, using the mac_* API can
> we register our receive callback function as the only callback
> receive function for the bge driver?
I don't think it's safe nor doable.
>
> Are we using the mac_* API correctly?
That's the crux of it, that's not a proper way to use the API.
Moreover, that API is consolidation private, and isn't safe to use
outside of ON. Unless you're planning on integrating your software into
ON, your software is subject to incompatible changes in the API.
- Maybe this (opensolaris) is the wrong place to look, though a Sun
escalation
- engineer refered us to opensolaris when we presented them with our
dilemma.
- Having an API that is reliable and will work with Solaris 10 is what we
need.
- Where can I find the official API?
- If Streams is the only answer, then we will look a little further before
biting
- that bullet. The sofware has been working for years now on all other
Solaris platforms
- and even the first patches of Solaris 10. It still works on some NIC's,
eg hme and eri.
- jim edele
> Maybe we need to do more
> than just a mac_open("/dev/bge0") and then mac_rx_add()? If we
> are not using it correctly, what other API functions do we need
> to call?
It depends on what your software does. You could look into implementing
a STREAMS module and also look into Darren's packet filtering hooks.
Without knowing what you want to do, it's hard to say...
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
