All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Timur Tabi <timur@codeaurora.org>,
	Lino Sanfilippo <LinoSanfilippo@gmx.de>,
	netdev@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, sdharia@codeaurora.org,
	shankerd@codeaurora.org, vikrams@codeaurora.org,
	cov@codeaurora.org, gavidov@codeaurora.org, robh+dt@kernel.org,
	andrew@lunn.ch, bjorn.andersson@linaro.org, mlangsdo@redhat.com,
	jcm@redhat.com, agross@codeaurora.org, davem@davemloft.net
Subject: Re: [PATCH] [v7] net: emac: emac gigabit ethernet controller driver
Date: Tue, 9 Aug 2016 18:25:26 -0700	[thread overview]
Message-ID: <85b76eca-5473-6724-0c9d-7b6fa7677f50@gmail.com> (raw)
In-Reply-To: <57AA7ED0.9000707@codeaurora.org>

On 08/09/2016 06:09 PM, Timur Tabi wrote:
> Florian Fainelli wrote:
> 
>> nr_frags can't be bigger than MAX_SKB_FRAGS, hence these checks all
>> other drivers do against 1 + MAX_SKB_FRAGS.
> 
> Doh, I just realized something.  emac_mac_tx_buf_send() just needs to
> make sure that there's enough room for ONE skb.  For some reason I
> thought it had to make sure there's enough room for multiple SKBs.
> 
> Now it makes a lot more sense.  Thank you.
> 
> So it looks like a given SKB can occupy 3 + nr_frags descriptors.  So I
> need to change that line to:
> 
>     if (emac_tpd_num_free_descs(tx_q) < (MAX_SKB_FRAGS + 3))
>         netif_stop_queue(adpt->netdev);
> 
> Question, some  drivers do <= instead of just <, like this:
> 
>     if (ring->free_bds <= (MAX_SKB_FRAGS + 1))
>         netif_tx_stop_queue(txq);
> 
> Is it necessary to stop the queue if there exactly enough descriptors to
> hold an SKB?  Shouldn't the above be this instead:
> 
>     if (ring->free_bds < (MAX_SKB_FRAGS + 1))
>         netif_tx_stop_queue(txq);

Humm, it kind of depends, but I would err on the side of strictly lesser
than as a better behavior where you may still allow a full fragmented
SKB to make it through on the next xmit call (I know the code you quote
is exactly not doing that).

> 
> 
>>> However, I'm confused about one thing.  Almost every other driver just
>>> sets "netdev->mtu = new_mtu" and does nothing else.  I can't find any
>>> other driver that actually stops the RX path, reprograms the hardware,
>>> and then restarts the RX path.  I know this is a stupid question, but
>>> why is my driver doing that?
>>
>> Most drivers allocate RX buffer sizes that are usually bigger than the
>> MTU, but would probably silently fail or expose transient behavior once
>> the MTU changes to greater than the size pre-defined.
> 
> So it looks like the real problem is a race condition between
> 
>     adpt->rxbuf_size = new_mtu > EMAC_DEF_RX_BUF_SIZE ?
>         ALIGN(max_frame, 8) : EMAC_DEF_RX_BUF_SIZE;
> 
> and
> 
>     if (netif_running(netdev))
>         return emac_reinit_locked(adpt);
> 
> 
> That is, if the interface is running, I set rxbuf_size.  If suddenly I
> receive some packets, then the driver will use the wrong buffer size.

Correct, and possibly other HW settings that you have may have to
program to tell the MAC what the maximum packet length should be.

> 
> Is there an easy way for me to stop the RX path before I set rxbuf_size?
>  Some netif_xxx function I can call?

napi_disable() should take care of that.
-- 
Florian

  reply	other threads:[~2016-08-10  1:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-03 20:12 [PATCH] [v7] net: emac: emac gigabit ethernet controller driver Timur Tabi
2016-08-04 17:55 ` Rob Herring
2016-08-04 18:18   ` Timur Tabi
2016-08-05 19:36   ` Timur Tabi
2016-08-15 20:06   ` Timur Tabi
2016-08-16 13:29     ` Rob Herring
2016-08-16 13:39       ` Timur Tabi
2016-08-16 21:20         ` Al Stone
2016-08-16 21:37           ` Timur Tabi
2016-08-17 19:25             ` Timur Tabi
     [not found]             ` <57B3878D.1000805-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-08-17 20:07               ` Florian Fainelli
2016-08-17 20:19                 ` Timur Tabi
     [not found]                   ` <57B4C6EE.3080903-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-08-17 22:32                     ` Timur Tabi
     [not found]                       ` <57B4E5F7.9040500-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-08-17 22:48                         ` Florian Fainelli
2016-08-18  3:27                           ` Timur Tabi
     [not found]                             ` <57B52B17.1080809-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-08-18  4:04                               ` Florian Fainelli
     [not found]                                 ` <5CCEFB33-8F93-40D7-BD32-ACDE1CBA586D-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-08-18  4:19                                   ` Timur Tabi
2016-08-18 16:09                                     ` Florian Fainelli
2016-08-18 17:56                                       ` Timur Tabi
     [not found] ` <1470255143-3979-1-git-send-email-timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-08-04 23:29   ` Lino Sanfilippo
2016-08-09 18:25     ` Timur Tabi
     [not found]       ` <57AA2001.2010904-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-08-09 18:39         ` Rob Herring
2016-08-09 19:34         ` Timur Tabi
2016-08-09 19:17       ` Florian Fainelli
     [not found]         ` <214dcbb7-0c3b-1e00-3e50-db513d77b10b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2016-08-10  1:09           ` Timur Tabi
2016-08-10  1:25             ` Florian Fainelli [this message]
2016-08-10 16:38               ` Timur Tabi
2016-08-10 17:49                 ` Florian Fainelli
2016-08-11 14:22                   ` Timur Tabi
2016-08-11 15:10                     ` Timur Tabi
2016-08-11 16:03                       ` Timur Tabi

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=85b76eca-5473-6724-0c9d-7b6fa7677f50@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=LinoSanfilippo@gmx.de \
    --cc=agross@codeaurora.org \
    --cc=andrew@lunn.ch \
    --cc=bjorn.andersson@linaro.org \
    --cc=cov@codeaurora.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=gavidov@codeaurora.org \
    --cc=jcm@redhat.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=mlangsdo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=sdharia@codeaurora.org \
    --cc=shankerd@codeaurora.org \
    --cc=timur@codeaurora.org \
    --cc=vikrams@codeaurora.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.