[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