All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joao Pinto <Joao.Pinto@synopsys.com>
To: Giuseppe CAVALLARO <peppe.cavallaro@st.com>,
	Joao Pinto <Joao.Pinto@synopsys.com>,
	Niklas Cassel <niklas.cassel@axis.com>,
	"Thierry Reding" <treding@nvidia.com>,
	Corentin Labbe <clabbe.montjoie@gmail.com>
Cc: David Miller <davem@davemloft.net>, <arnd@arndb.de>,
	<alexandre.torgue@st.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues
Date: Mon, 3 Apr 2017 14:12:10 +0100	[thread overview]
Message-ID: <21934325-6d37-7aea-793f-71fac2c40bf3@synopsys.com> (raw)
In-Reply-To: <799c7a4b-767e-b21c-d3bf-8fd3b639d70f@st.com>


Hello Peppe,

Às 2:07 PM de 4/3/2017, Giuseppe CAVALLARO escreveu:
> Hello Joao
> 
> On 3/30/2017 6:42 PM, Joao Pinto wrote:
>> Às 5:35 PM de 3/30/2017, Niklas Cassel escreveu:
>>> On 03/30/2017 04:34 PM, Thierry Reding wrote:
>>>> On Thu, Mar 30, 2017 at 09:45:36AM +0200, Corentin Labbe wrote:
>>>>> On Tue, Mar 28, 2017 at 06:01:05PM -0700, David Miller wrote:
>>>>>> From: Arnd Bergmann <arnd@arndb.de>
>>>>>> Date: Tue, 28 Mar 2017 11:48:21 +0200
>>>>>>
>>>>>>> A driver must not access the two fields directly but should instead use
>>>>>>> the helper functions to set the values and keep a consistent internal
>>>>>>> state:
>>>>>>>
>>>>>>> ethernet/stmicro/stmmac/stmmac_main.c: In function 'stmmac_dvr_probe':
>>>>>>> ethernet/stmicro/stmmac/stmmac_main.c:4083:8: error: 'struct net_device'
>>>>>>> has no member named 'real_num_rx_queues'; did you mean 'real_num_tx_queues'?
>>>>>>>
>>>>>>> Fixes: a8f5102af2a7 ("net: stmmac: TX and RX queue priority configuration")
>>>>>>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>>>>> Applied.
>>>>> This break my revert patch. (since it patch ("net: stmmac: enable multiple
>>>>> buffers").
>>>>> Since dwmac-sunxi is still broken, what can I do ? send two revert patch ?
>>>>> or adapt the reverting patch.
>>>> Have you tried if the kcalloc() patch I sent on Tuesday fixes things the
>>>> issues introduced by the multiple buffers patch? Niklas reported that it
>>>> restores functionality on his setup.
>>>>
>>>> If it makes things work for you as well, we could maybe avoid the revert
>>>> altogether.
>>> Thierry, I know that you are using DWMAC CORE 4.XX
>>> How many RX queues and how many TX queues have you got?
>>>
>>> I'm also using DWMAC CORE 4.XX
>>> We have 2 TX queues and 1 RX queue.
>>>
>>> I think that Corentin is using DWMAC CORE 3.XX
>>>
>>> I know that Joao is using an IP Prototyping Kit that uses
>>> DWMAC CORE 4.XX (connected via PCIe).
>>> It would be nice if Joao could get an IP Prototyping Kit
>>> based on DWMAC CORE 3.XX.
>>>
>>> Doesn't Synopsys have an IP Prototyping Kit based on
>>> DWMAC CORE 3.XX laying around somewhere? :)
>>>
>> I requested a prototyping platform with MAC 100 or a MAC 1000 in order to make
>> more tests, but I don't have an ETA for it yet.
>>
>> The implication of the multiple buffers patch in 3.xx is some flow change in the
>> configuration of dma op mode or similar. I would recomend Corentin to dump the
>> dma & mac registers in the end of the _open function in order to see if the DMA
>> is really being well configured and is really started.
> 
> Old devices managed as stmmac: mac10/100 platform driver have no multi-queue
> support.
> 
> It was introduced in the new versions managed by mac1000 but in my opinion
> the stmmac driver has to only work with a single queue for tx and rx on ALL
> the 3.x versions.
> 
> In fact, although the latest series have the multi-queue and channels there is
> just one IRQ and this is a very poor implementation.
> The 3.xx is very different from what we have in the 4.XX (QoS) on this part and
> AV/B.
> 
> Nobody has ever asked for having this support in all these years for the previous
> chips.
> 
> Adding this kind of support we'll spend time for having a no useful optimization
> and risking to break the compatibility with a lot platforms that use these chips.
> 
> I image, multi-queue stable on 4.XX and no support on all older versions.
> Let me know if you share that.

Yes older cores do not support multiple queues and I tried to isolate the
features not to affect older versions.

Do you think that functions as "ndev = alloc_etherdev_mqs" has some sort of
influence?

Thanks.

> 
> Regards
> Peppe
> 
>>
>> Thanks.
>>
>> Joao
>>
>>
> 

  reply	other threads:[~2017-04-03 13:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-28  9:48 [PATCH] [net-next] stmmac: use netif_set_real_num_{rx,tx}_queues Arnd Bergmann
2017-03-29  1:01 ` David Miller
2017-03-30  7:45   ` Corentin Labbe
2017-03-30 14:34     ` Thierry Reding
2017-03-30 16:35       ` Niklas Cassel
2017-03-30 16:42         ` Joao Pinto
2017-04-03 13:07           ` Giuseppe CAVALLARO
2017-04-03 13:12             ` Joao Pinto [this message]
2017-04-04  6:15               ` Giuseppe CAVALLARO
2017-03-30 17:48       ` David Miller
2017-03-31 10:14         ` Joao Pinto
2017-03-31 10:43           ` Joao Pinto
2017-03-31 16:57             ` David Miller
2017-03-31 16:58               ` Joao Pinto

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=21934325-6d37-7aea-793f-71fac2c40bf3@synopsys.com \
    --to=joao.pinto@synopsys.com \
    --cc=alexandre.torgue@st.com \
    --cc=arnd@arndb.de \
    --cc=clabbe.montjoie@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=niklas.cassel@axis.com \
    --cc=peppe.cavallaro@st.com \
    --cc=treding@nvidia.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 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.