From: Claudiu Manoil <claudiu.manoil@freescale.com>
To: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: <netdev@vger.kernel.org>, "David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH net-next 5/5] gianfar: Fix and cleanup Rx FCB handling
Date: Wed, 13 Feb 2013 13:34:43 +0200 [thread overview]
Message-ID: <511B7A53.3060800@freescale.com> (raw)
In-Reply-To: <511A799C.4020105@windriver.com>
On 2/12/2013 7:19 PM, Paul Gortmaker wrote:
> On 13-02-12 07:47 AM, Claudiu Manoil wrote:
>> NETIF_F_HW_VLAN_TX flag must not condition RxFCB usage.
>
> The above statement isn't 100% clear to me. Is this the intent?
The above statement is a rule, if you wish. The existing code breaks
that rule by saying: RxFCB is enabled if NETIF_F_HW_VLAN_TX; which is
a false statement. This patch corrects this error, according to the
rule above.
So, primarily, this patch is a fix (as expressed in <subj.>). I'll
resend the patch with additional comments to make this point clearer.
>
> Currently, gfar_uses_fcb() calls gfar_is_vlan_on() which in turn
> checks NETIF_F_HW_VLAN_TX. However there is no relation between
> whether FCBs are used and the VLAN transmit state.
>
>> In the case of RxBD rings, FCBs (Frame Control Block) are inserted by
>> the eTSEC whenever RCTRL[PRSDEP] is set to a non-zero value. Only one
>> FCB is inserted per frame (in the buffer pointed to by the RxBD with
>> bit F set). TOE acceleration for receive is enabled for all rx frames
>> in this case.
>> Indroduce the uses_rxfcb field to signal RxFCB insertion in accordance
>> with the specification above (leading to cleaner, less confusing code).
>
> The is_vlan_on() and uses_fcb() calls were more self documenting than
> setting/clearing a new single use variable added to priv, I think.
> Even if they get changed/simplified, perhaps it is worth keeping them?
gfar_uses_fcb() generates confusion around the FCB concept, this maybe
explains how it came to the error above. First, there are 2 types of
FCBs with different meaning, covering different use cases: Rx (receive
side) FCB and TxFCB. uses_fcb() was intended to signal RxFCB insertion,
which is not obvious from its name, and it became (subtly) erroneous
after incorporating is_vlan_on().
is_vlan_on() is also misleading because we need to differentiate b/w
hw VLAN extraction/VLEX (marked by VLAN_RX flag) and hw VLAN
insertion/VLINS (VLAN_TX flag), which are different mechanisms using
different types of FCBs.
>
> Rather than a specific priv->uses_rxfcb field, perhaps it makes sense
> to make it more future proof with priv->rctrl field, that is a cached
> value of the register, and then you keep gfar_uses_fcb() and it in
> turn checks for RCTRL_PRSDEP_INIT bit in rctrl?
>
The main purpose of the priv->uses_rxfcb field is to quickly signal, on
the hot path, that the incoming frame has a *Rx* FCB block inserted
which needs to be pulled out before passing the skb to the stack.
This is a performance critical operation, it needs to happen fast,
that's why uses_rxfcb is placed in the first cacheline of gfar_private.
This is also why I cannot use a cached rctrl instead: 1) because I
don't have 32 bits available in the first cacheline of gfar_probe
(but only 16); 2) no time for bit operations on the hot path.
> Also, the dependency/conditional on FSL_GIANFAR_DEV_HAS_TIMER seems
> to simply vanish with this patch, and it isn't clear to me if that
> was 100% intentional or not...
>
The dependency on FSL_GIANFAR_DEV_HAS_TIMER is another source of
confusion. The dependency is actually to priv->hwts_rx_en.
Upon changing priv->hwts_rx_en via IOCTL, the gfar device is being
restarted and on init_mac() the priv->hwts_rx_en conditions the RxFCB
insertion, and rctrl is programmed accordingly. The patch takes care
of this case too.
So, I'll re-spin this patch with enhanced comments.
Thanks,
Claudiu
next prev parent reply other threads:[~2013-02-13 11:34 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-12 12:47 [PATCH net-next 1/5] gianfar: Cleanup device refs in gfar_private Claudiu Manoil
2013-02-12 12:47 ` [PATCH net-next 2/5] gianfar: Cleanup and optimize struct gfar_private Claudiu Manoil
2013-02-12 12:47 ` [PATCH net-next 3/5] gianfar: GRO_DROP is unlikely Claudiu Manoil
2013-02-12 12:47 ` [PATCH net-next 4/5] gianfar: Remove wrong buffer size conditioning to VLAN h/w offload Claudiu Manoil
2013-02-12 12:47 ` [PATCH net-next 5/5] gianfar: Fix and cleanup Rx FCB handling Claudiu Manoil
2013-02-12 17:19 ` Paul Gortmaker
2013-02-13 11:34 ` Claudiu Manoil [this message]
2013-02-13 14:32 ` Paul Gortmaker
2013-02-12 16:30 ` [PATCH net-next 3/5] gianfar: GRO_DROP is unlikely Paul Gortmaker
2013-02-12 16:47 ` Eric Dumazet
2013-02-12 17:05 ` Claudiu Manoil
2013-02-12 15:11 ` [PATCH net-next 2/5] gianfar: Cleanup and optimize struct gfar_private Paul Gortmaker
2013-02-12 15:58 ` Claudiu Manoil
2013-02-12 16:49 ` Paul Gortmaker
2013-02-12 14:54 ` [PATCH net-next 1/5] gianfar: Cleanup device refs in gfar_private Paul Gortmaker
2013-02-12 17:14 ` Claudiu Manoil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=511B7A53.3060800@freescale.com \
--to=claudiu.manoil@freescale.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=paul.gortmaker@windriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).