[Avila] Gateworks and the Intel NPEs

Dave G daveg at unixstudios.net
Fri Jan 5 15:00:00 EST 2007


Hi Travis/List,

I can comment on the roadmap question. Our plans are to include latest IAL 
as well as the GPL driver in our next BSP release so you can choose either 
to use.
We currently don't have plans to dig into the IAL code to do repair work, 
however if the next IAL release exhibits the same issues previous releases 
have we likely would dig into it to see what we can find. As you all know 
the IAL code is developed and provided by Intel and not by Gateworks.

My own thoughts on the reported IAL/NPE issues are probably not shared by 
most. Because it seems that the reported IAL issues persist over different 
versions of the IAL and also since Intel has failed to acknowledge and/or 
repair the reported issues, I suspect that there may not be any issues 
whatsoever in the IAL or if there are they may be very minor. I find it hard 
to believe that Intel would continue to release IAL versions which exhibit 
the same reported issues without Intel doing anything about it if such 
issues indeed existed and were validated by Intel. I realize that many of 
the IAL releases are just feature/cpu upgrades and not always fixes.

IMHO I think that the reported issues could very well be related to the 
environment or manner in which many of us use the NPEs.

For example, the npe_learning=0 argument passed to the ixp400_eth module 
turns off MAC learning in the IAL/driver. This argument MUST be used if the 
NPE is to be a part of a bridge where MAC learning is already being done 
(Linux ethernet bridging). Without turning off npe_learning in the IAL some 
funky things happen.
Looking at the various available microcode (the microcode loaded into the 
NPE) and the different features that each of them employ causes me to 
suspect that I might have a problem down the road because the IAL is doing 
something like:

NPEA_ETH_SPAN_MASK_FIREWALL_VLAN_QOS_HDR_CONV_EXTMIB
NPEA_ETH_SPAN_VLAN_QOS_HDR_CONV_EXTMIB
NPEA_ETH_LEARN_FILTER_SPAN_MASK_FIREWALL_VLAN_QOS_EXTMIB
NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QOS
NPEB_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV

yet I am planning on doing some of the same in the kernel via iprout2, 
iptables, etc, etc.

I haven't looked deeply into even if the above features are actually being 
performed in the NPE or how to control them, except that I know using 
npe_learning=0 absolutely cleans up the bridging issues I was experiencing 
when ixp0/ixp1 was part of a bridge group. Additionally I haven't looked 
specifically at the ramifications of the NPE microcode doing something like 
HDR_CONV while I am doing iptables -t mangle stuff.

Anyway, if we end up experiencing IAL/NPE issues after this next BSP release 
I would suspect that we would begin looking in the above described areas.

Thanks!

-Dave G

Hey list,

    I am just wondering where Gateworks stands with the Intel NPEs. We've 
all seen the posts about the receive buffer problems (in promiscuous mode) 
some of us have had with the Intel driver currently released with the BSPs. 
Currently, we still have this issue and it remains a big problem for us. 
This of course doesn't allow a confident Wi-fi access point.

    I have seen that a lot of you are switching over to the open source NPE 
driver, NSLU2 correct? Is this the direction that everyone is going and does 
Gateworks have a roadmap to possibly solve the issue with the BSP released 
NPE driver? Or are they recommending everyone just use the open source 
version?

    Hopefully this ends up being an easy answer. I know a few of us have 
looked at this ourselves, in particular David Acker. Some of the things 
David had found ended up not working for both of us. However, I have tried 
what was last stated by David and Dave G on regards to the modprobe line:

    modprobe ixp400
    cat /etc/IxNpeMicrocode.dat > /dev/ixNpe
    modprobe ixp400_eth npe_learning=0

    Even with adding the npe_learning=0 option for the modprobe of 
ixp400_eth, we have still seen periods of dropped packets just as before. 
Any thoughts would be greatly appreciated. Thanks.

Travis 





More information about the Avila mailing list