[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimgKN3ddBR=PjB9PXgwDmOfDESaVNFp33GR6E+g@mail.gmail.com>
Date: Tue, 26 Oct 2010 10:57:38 -0700
From: Jesse Gross <jesse@...ira.com>
To: Vladislav Zolotarov <vladz@...adcom.com>
Cc: David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Hao Zheng <hzheng@...ira.com>,
Eilon Greenstein <eilong@...adcom.com>
Subject: Re: [PATCH v2 11/14] bnx2x: Update bnx2x to use new vlan accleration.
On Tue, Oct 26, 2010 at 2:14 AM, Vladislav Zolotarov <vladz@...adcom.com> wrote:
>>
>> Even though the fix prevents the panic, I'm still a little concerned
>> that you ran into it at all when vlan stripping was disabled. That
>> function should only be called when a tag was received by the card.
>> Is it possible that __vlan_hwaccel_put_tag is being called even in
>> cases when no tag was stripped?
>
> Correct, and that's because u've patched the driver to put it the
> following way:
>
> if (le16_to_cpu(cqe->fast_path_cqe.pars_flags.flags) &
> PARSING_FLAGS_VLAN)
> __vlan_hwaccel_put_tag(skb, le16_to_cpu(cqe->fast_path_cqe.vlan_tag));
>
> The condition above will be TRUE regardless VLAN stripping is enabled or
> disabled as the parsing flags come from our PARSER HW block and simply
> indicates whether this frame has a VLAN header or not. When I disabled a VLAN
> stripping I should have fixed this lines too but I think I didn't... ;)
>
>> Maybe we made a mistake when converting the driver?
>
> Since the driver always configures the VLAN stripping now, regardless the kernel
> configuration, I think your patch was just fine. ;)
Great. Thanks for the explanation and confirmation.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists