This one bit me hard several months ago. Your analysis is correct.
It's a hardware bug. The solution is to track in the driver whether
the VME bit is set for the given queue, and if it isn't, ignore the VP
bit.
I meant to report this one to Jack but forgot, evidently.
Ryan Stone
___
Hello,
I was adding a static route and "accidentally" put an extra number 1
after the command, like this:
route add -net 192.168.0.100 192.168.0.200 255.255.255.255 1
netstat -rn prints:
Routing tables
Internet:
DestinationGatewayFlagsRefs Use Netif Expire
0.0.0
Hmmm, so you're saying the VP get's set when it shouldn't ? I'm not sure
I follow the logic of how that would result in what he is seeing? I'm
wondering
if this might also have to do with a problem reported with IPv6 forwarding
and
vlans??
At least I can code this simply enough.
Jack
On Fri, No
If vlan stripping is disabled on the 82599(i.e. RXDCTL.VME is 0 for
that queue is clear) and a vlan-tagged packet is received, then the
descriptor for that packet will have the VP bit set even though the
vlan was not stripped, and the VLAN Tag field in the descriptor is set
to 0. ixgbe_rxeof will
Ahh, OK, so how would this solution work:
In rxeof, in addition to requiring VP to be set, also check that
adapter->num_vlans
is non-zero, in order to store the tag.
Jack
On Fri, Nov 26, 2010 at 12:42 PM, Ryan Stone wrote:
> If vlan stripping is disabled on the 82599(i.e. RXDCTL.VME is 0 for
On Fri, Nov 26, 2010 at 3:46 PM, Jack Vogel wrote:
> Ahh, OK, so how would this solution work:
>
> In rxeof, in addition to requiring VP to be set, also check that
> adapter->num_vlans is non-zero, in order to store the tag.
>
> Jack
Yes, I believe that will work.
Ryan Stone
On 11/13/10 00:18, Lawrence Stewart wrote:
> On 11/12/10 21:41, Kostik Belousov wrote:
>> On Fri, Nov 12, 2010 at 09:21:29PM +1100, Lawrence Stewart wrote:
>>> On 11/12/10 20:44, Lawrence Stewart wrote:
On 11/07/10 17:32, Lawrence Stewart wrote:
> On 11/03/10 09:30, Andre Oppermann wrote:
Will you please test with the code I just checked in and
see if it also eliminates the problem, if not I can change
it to your method.
Just for the record, I was not aware of a hardware bug, and
for right now no one is around :) I will ask around next week
to see if something was known that I miss
