Re: [mpls-linux-devel] Current state of dst stacking on davem implementation

[Jamal H. S. <ha...@zn...>]

Hi James,
I didnt apply the patch or test it but it looks clean. I like some of
the cleanups.
I wasnt sure about a few things (which maybe harder to see because i am
reading a patch);
1) ipv4/fib_semantics.c, you got rid of the check:

--
if (fi->fib_nh && fi->fib_nh->nh_mpls_fec) {
---

Is this in the spirit of avoiding refcount inc/dec?
BTW, i think it is a good idea to probably keep the refcounts inc/dec;
What is the main reason you are trying to get rid of them?

2) You no longer do a mpls_bind_neighbour(); is this covered elsewhere?

3) The check:
     if (NULL != mpls) {
               int usrs = atomic_read(&mpls->mr_ref);

is to ensure that no user apace deleted a nhlfe entry while some
other place is using it.

4) I suppose mpls_nhlfe_release() is no longer needed now because
of the refcounting changes?

Anyways, overall i would say this is an improvement and we should
have no challenges getting past Davem.

On Mon, 2004-03-01 at 00:03, James R. Leu wrote:
> I've attached a patch against the head of line of the p4 depot for the davem
> implementation.  I tested the output path and it correctly generates MPLS
> packets.  I was unable to figure out the correct combination of l2c
> commands on the input side.  So I gave up testing the input path for
> tonight.  I thought I'd send out what I have so you can look it over and
> get an understanding of where I'm heading with this change.  Of course you
> could always look at the latest changes to my implementation and you'd
> probably get an even better idea ;-)
> 
> Items left to be resolved:
> -correct l2c command line for input definition?  (are we open for discussing
>  changes?)

This is my domain and i am open. Lets just make sure that the ideas
have minimal impact on Daves code and 2 they are guided by useful
changes as opposed to sentimental ones (example "this is how we did it
before").

cheers,
jamal