On 12/14/2016 01:57 PM, Pavel Machek wrote:
> Hi!
>
>> So if there is a long time before handling interrupts,
>> I guess that it makes sense that one stream could
>> get an advantage in the net scheduler.
>>
>> If I find the time, and if no one beats me to it, I will try to replace
>> the normal ti
On 12/13/2016 01:56 PM, Joao Pinto wrote:
> Às 12:50 PM de 12/13/2016, Lars Persson escreveu:
>>> 13 dec. 2016 kl. 13:31 skrev Niklas Cassel :
>>>
>>>
>>>
On 12/13/2016 12:49 PM, Joao Pinto wrote:
Hi Niklas,
Às 4:25 PM de 12/12/2016, Niklas Cassel escreveu:
>> On 12/12/2016
Às 10:55 AM de 12/19/2016, Joao Pinto escreveu:
>
> Hi Pavel,
>
> Às 5:38 PM de 12/17/2016, Pavel Machek escreveu:
>> Hi!
>>
> So if there is a long time before handling interrupts,
> I guess that it makes sense that one stream could
> get an advantage in the net scheduler.
>
Hi Pavel,
Às 5:38 PM de 12/17/2016, Pavel Machek escreveu:
> Hi!
>
So if there is a long time before handling interrupts,
I guess that it makes sense that one stream could
get an advantage in the net scheduler.
If I find the time, and if no one beats me to it, I will try
Hi!
> >> So if there is a long time before handling interrupts,
> >> I guess that it makes sense that one stream could
> >> get an advantage in the net scheduler.
> >>
> >> If I find the time, and if no one beats me to it, I will try to replace
> >> the normal timers with HR timers + a smaller def
On 12/14/2016 01:57 PM, Pavel Machek wrote:
> Hi!
>
>> So if there is a long time before handling interrupts,
>> I guess that it makes sense that one stream could
>> get an advantage in the net scheduler.
>>
>> If I find the time, and if no one beats me to it, I will try to replace
>> the normal ti
Hi!
> I know that this is completely of topic, but I am facing a dificulty with
> stmmac. I have interrupts, mac well configured rx packets being received
> successfully, but TX is not working, resulting in Tx errors = Total TX
> packets.
> I have made a lot of debug and my conclusions is that by
Hi!
> I know that this is completely of topic, but I am facing a dificulty with
> stmmac. I have interrupts, mac well configured rx packets being received
> successfully, but TX is not working, resulting in Tx errors = Total TX
> packets.
> I have made a lot of debug and my conclusions is that by
Hi,
Às 12:57 PM de 12/14/2016, Pavel Machek escreveu:
> Hi!
>
>> So if there is a long time before handling interrupts,
>> I guess that it makes sense that one stream could
>> get an advantage in the net scheduler.
>>
>> If I find the time, and if no one beats me to it, I will try to replace
>>
Hi!
> So if there is a long time before handling interrupts,
> I guess that it makes sense that one stream could
> get an advantage in the net scheduler.
>
> If I find the time, and if no one beats me to it, I will try to replace
> the normal timers with HR timers + a smaller default timeout.
>
Hi!
> There are some performance problems with the stmmac driver though:
>
> When running iperf3 with 3 streams:
> iperf3 -c 192.168.0.90 -P 3 -t 30
> iperf3 -c 192.168.0.90 -P 3 -t 30 -R
>
> I get really bad fairness between the streams.
>
> This appears to be an issue with how TX IRQ coalesci
Às 12:50 PM de 12/13/2016, Lars Persson escreveu:
>
>> 13 dec. 2016 kl. 13:31 skrev Niklas Cassel :
>>
>>
>>
>>> On 12/13/2016 12:49 PM, Joao Pinto wrote:
>>> Hi Niklas,
>>>
>>> Às 4:25 PM de 12/12/2016, Niklas Cassel escreveu:
> On 12/12/2016 11:19 AM, Joao Pinto wrote:
> Hi,
>
>
> 13 dec. 2016 kl. 13:31 skrev Niklas Cassel :
>
>
>
>> On 12/13/2016 12:49 PM, Joao Pinto wrote:
>> Hi Niklas,
>>
>> Às 4:25 PM de 12/12/2016, Niklas Cassel escreveu:
>>>
On 12/12/2016 11:19 AM, Joao Pinto wrote:
Hi,
Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
>
On 12/13/2016 12:49 PM, Joao Pinto wrote:
> Hi Niklas,
>
> Às 4:25 PM de 12/12/2016, Niklas Cassel escreveu:
>>
>> On 12/12/2016 11:19 AM, Joao Pinto wrote:
>>> Hi,
>>>
>>> Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
Le 12/09/16 à 16:16, Andy Shevchenko a écrit :
> On Sat, Dec 1
Hi Niklas,
Às 4:25 PM de 12/12/2016, Niklas Cassel escreveu:
>
>
> On 12/12/2016 11:19 AM, Joao Pinto wrote:
>> Hi,
>>
>> Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
>>> Le 12/09/16 à 16:16, Andy Shevchenko a écrit :
On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli
wrote:
Hello Niklas
On 12/13/2016 10:38 AM, Niklas Cassel wrote:
On 12/13/2016 08:22 AM, Giuseppe CAVALLARO wrote:
On 12/12/2016 5:25 PM, Niklas Cassel wrote:
On 12/12/2016 11:19 AM, Joao Pinto wrote:
Hi,
Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
Le 12/09/16 à 16:16, Andy Shevchenko a
On 12/13/2016 08:22 AM, Giuseppe CAVALLARO wrote:
> On 12/12/2016 5:25 PM, Niklas Cassel wrote:
>>
>>
>> On 12/12/2016 11:19 AM, Joao Pinto wrote:
>>> Hi,
>>>
>>> Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
Le 12/09/16 à 16:16, Andy Shevchenko a écrit :
> On Sat, Dec 10, 2016 at 1
On 12/12/2016 5:25 PM, Niklas Cassel wrote:
On 12/12/2016 11:19 AM, Joao Pinto wrote:
Hi,
Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
Le 12/09/16 à 16:16, Andy Shevchenko a écrit :
On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli wrote:
It's kind of sad that customers of that
Niklas Cassel wrote at Monday, December 12, 2016 9:25 AM:
...
> However, I've noticed that NVIDIA has extended the DWC EQoS DT binding,
> I don't how easy it would be for them to switch to stmmac's DT binding.
> (Adding Stephen Warren to CC.)
I don't believe there's any issue switching drivers, so
On 12/12/2016 11:19 AM, Joao Pinto wrote:
> Hi,
>
> Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
>> Le 12/09/16 à 16:16, Andy Shevchenko a écrit :
>>> On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli
>>> wrote:
>>>
It's kind of sad that customers of that IP (stmmac, amd-xgbe, sxg
Hello All.
On 12/12/2016 11:19 AM, Joao Pinto wrote:
Hi,
Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
Le 12/09/16 à 16:16, Andy Shevchenko a écrit :
On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli wrote:
It's kind of sad that customers of that IP (stmmac, amd-xgbe, sxgbe)
did
Hi,
Às 1:44 AM de 12/10/2016, Florian Fainelli escreveu:
> Le 12/09/16 à 16:16, Andy Shevchenko a écrit :
>> On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli
>> wrote:
>>
>>> It's kind of sad that customers of that IP (stmmac, amd-xgbe, sxgbe)
>>
>>> did
>>> actually pioneer the upstreaming ef
On 2016/12/10 8:16, Andy Shevchenko wrote:
> On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli
> wrote:
>
>> It's kind of sad that customers of that IP (stmmac, amd-xgbe, sxgbe)
>> did
>> actually pioneer the upstreaming effort, but it is good to see people
>> from Synopsys willing to fix that
Le 12/09/16 à 16:16, Andy Shevchenko a écrit :
> On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli
> wrote:
>
>> It's kind of sad that customers of that IP (stmmac, amd-xgbe, sxgbe)
>
>> did
>> actually pioneer the upstreaming effort, but it is good to see people
>> from Synopsys willing to fi
On Sat, Dec 10, 2016 at 12:52 AM, Florian Fainelli wrote:
> It's kind of sad that customers of that IP (stmmac, amd-xgbe, sxgbe)
> did
> actually pioneer the upstreaming effort, but it is good to see people
> from Synopsys willing to fix that in the future.
Wait, you would like to tell that we
On 12/09/2016 02:25 PM, Andy Shevchenko wrote:
> On Fri, Dec 9, 2016 at 5:41 PM, David Miller wrote:
>
>> But one thing I am against is changing the driver name for existing
>> users. If an existing chip is supported by the stmmac driver for
>> existing users, they should still continue to use t
On Fri, Dec 9, 2016 at 5:41 PM, David Miller wrote:
> But one thing I am against is changing the driver name for existing
> users. If an existing chip is supported by the stmmac driver for
> existing users, they should still continue to use the "stmmac" driver.
>
> Therefore, if consolidation ch
Às 3:41 PM de 12/9/2016, David Miller escreveu:
> From: Joao Pinto
> Date: Fri, 9 Dec 2016 15:36:38 +
>
>> Of course, I started a general discussion about the subject and
>> those were the conclusions, but I would like to know if you as the
>> subsystem maintainer also support the approach or
From: Joao Pinto
Date: Fri, 9 Dec 2016 15:36:38 +
> Of course, I started a general discussion about the subject and
> those were the conclusions, but I would like to know if you as the
> subsystem maintainer also support the approach or have any
> suggestion.
Generally, I support whatever th
Hi David,
Of course, I started a general discussion about the subject and those were the
conclusions, but I would like to know if you as the subsystem maintainer also
support the approach or have any suggestion.
Thanks,
Joao
Às 3:33 PM de 12/9/2016, David Miller escreveu:
> From: Joao Pinto
> D
From: Joao Pinto
Date: Fri, 9 Dec 2016 11:29:02 +
> Dear David Miller,
...
> I would like to know if you support this plan.
This is not how this works.
You need to discuss and work out a plan with the other people
with a direct interest in the existing drivers and maintainence.
Not me.
Dear David Miller,
These past 2 weeks we have been discussing the right way to go in terms of
Synopsys QoS support in the kernel.
The approach that raised more supporters was:
a) Test /stmicro/stmmac driver in a reference hardware prototyping platform (QoS
IPK) [Status: In Progress | 90% finishe
On Mon, Nov 21, 2016 at 2:52 PM, Giuseppe CAVALLARO
wrote:
First of all, +1 to (re-)use stmmac.
> The stmmac drivers run since many years on several platforms
> (sh4, stm32, arm, x86, mips ...) and it supports an huge of amount of
> configurations starting from 3.1x to 3.7x databooks.
As Intel
Hi!
> > Thanks!
>
> Regarding this subject, I am thinking of making the following adaption:
>
> a) delete ethernet/synopsys
> b) rename ethernet/stmicro/stmmac to ethernet/synopsys
>
> and send you a patch for you to evaluate. Both agree with the approach?
> To have a new work base would be imp
On 11/23/2016 12:43 PM, Joao Pinto wrote:
> Rabin Vincent can review and test that the port works properly on our
Artpec-chips that use dwc_eth_qos.c today.
>
> The main porting step is to implement the device tree binding in
bindings/net/snps,dwc-qos-ethernet.txt. Also our chip has a strict re
On 23-11-2016 11:41, Lars Persson wrote:
>
>> 23 nov. 2016 kl. 12:11 skrev Joao Pinto :
>>
>> Hi Peppe and Lars,
>>
>>> On 23-11-2016 10:59, Giuseppe CAVALLARO wrote:
>>> Hello Joao, Lars.
>>>
On 11/22/2016 3:16 PM, Joao Pinto wrote:
>> Ok, it makes sense.
>> Just for curiosity the ta
> 23 nov. 2016 kl. 12:11 skrev Joao Pinto :
>
> Hi Peppe and Lars,
>
>> On 23-11-2016 10:59, Giuseppe CAVALLARO wrote:
>> Hello Joao, Lars.
>>
>>> On 11/22/2016 3:16 PM, Joao Pinto wrote:
> Ok, it makes sense.
> Just for curiosity the target setup is the following:
> https://www.you
Hi Peppe and Lars,
On 23-11-2016 10:59, Giuseppe CAVALLARO wrote:
> Hello Joao, Lars.
>
> On 11/22/2016 3:16 PM, Joao Pinto wrote:
>>> Ok, it makes sense.
>>> > Just for curiosity the target setup is the following:
>>> > https://www.youtube.com/watch?v=8V-LB5y2Cos
>>> > but instead of using inter
Hello Joao, Lars.
On 11/22/2016 3:16 PM, Joao Pinto wrote:
Ok, it makes sense.
> Just for curiosity the target setup is the following:
> https://www.youtube.com/watch?v=8V-LB5y2Cos
> but instead of using internal drivers, we desire to use mainline drivers only.
>
> Thanks!
Regarding this subjec
Hello Ozgur
On 11/22/2016 9:38 AM, Ozgur Karatas wrote:
Hello all,
I think, ethtool and mdio don't work because the tool's not support to "QoS",
right?
Maybe, need a new API. I'm looking for dwceqos code but "tc" tools is very idea.
I hope to be me always helpful.
tools work but indeed sho
;>>>>>> Hello,
>>>>>>>
>>>>>>>>> On 21-11-2016 05:29, Rayagond Kokatanur wrote:
>>>>>>>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent wrote:
>>>>>>>>>> On Fri, Nov
Kokatanur wrote:
>>>>>>>>> On Sat, Nov 19, 2016 at 7:26 PM, Rabin Vincent wrote:
>>>>>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +0000, Joao Pinto wrote:
>>>>>>>>> For now we are interesting in improving the syn
rote:
>>>>>>>> On Fri, Nov 18, 2016 at 02:20:27PM +, Joao Pinto wrote:
>>>>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>>>>> /nect/ethernet/synopsys. For now the driver structure con
On 21-11-2016 15:03, Giuseppe CAVALLARO wrote:
> On 11/21/2016 4:00 PM, Joao Pinto wrote:
>> On 21-11-2016 14:36, Giuseppe CAVALLARO wrote:
>>> Hello Joao
>>>
>>> On 11/21/2016 2:48 PM, Joao Pinto wrote:
Synopsys QoS IP is a separated hardware component, so it should be
reusable by
On 21-11-2016 14:36, Giuseppe CAVALLARO wrote:
> Hello Joao
>
> On 11/21/2016 2:48 PM, Joao Pinto wrote:
>> Synopsys QoS IP is a separated hardware component, so it should be reusable
>> by
>> all implementations using it and so have its own "core driver" and platform +
>> pci glue drivers. This
now we are interesting in improving the synopsys QoS driver under
>>>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a
>>>>>>> single file
>>>>>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops
On 11/21/2016 4:00 PM, Joao Pinto wrote:
On 21-11-2016 14:36, Giuseppe CAVALLARO wrote:
Hello Joao
On 11/21/2016 2:48 PM, Joao Pinto wrote:
Synopsys QoS IP is a separated hardware component, so it should be reusable by
all implementations using it and so have its own "core driver" and platform
Hello Joao
On 11/21/2016 2:48 PM, Joao Pinto wrote:
Synopsys QoS IP is a separated hardware component, so it should be reusable by
all implementations using it and so have its own "core driver" and platform +
pci glue drivers. This is necessary for example in hardware validation, where
you proto
:27PM +, Joao Pinto wrote:
For now we are interesting in improving the synopsys QoS driver under
/nect/ethernet/synopsys. For now the driver structure consists of a single file
called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform
related stuff.
Our strategy would be:
a
; On Fri, Nov 18, 2016 at 02:20:27PM +, Joao Pinto wrote:
>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a single
>>>>> file
>>>>&g
gt;>>>> On Fri, Nov 18, 2016 at 02:20:27PM +, Joao Pinto wrote:
>>>>> For now we are interesting in improving the synopsys QoS driver under
>>>>> /nect/ethernet/synopsys. For now the driver structure consists of a
>>>>> single file
/nect/ethernet/synopsys. For now the driver structure consists of a single file
called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform
related stuff.
Our strategy would be:
a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
b) Implement a pci glue driver
ynopsys. For now the driver structure consists of a single
>>> file
>>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and
>>> platform
>>> related stuff.
>>>
>>> Our strategy would be:
>>>
>>> a) Implement
t;> file
>> called dwc_eth_qos.c, containing synopsys ethernet qos common ops and
>> platform
>> related stuff.
>>
>> Our strategy would be:
>>
>> a) Implement a platform glue driver (dwc_eth_qos_pltfm.c)
>> b) Implement a pci glue driver (dwc_eth_qos_pci.c)
On Fri, Nov 18, 2016 at 02:20:27PM +, Joao Pinto wrote:
> For now we are interesting in improving the synopsys QoS driver under
> /nect/ethernet/synopsys. For now the driver structure consists of a single
> file
> called dwc_eth_qos.c, containing synopsys ethernet qos common ops
On Fri, 2016-11-18 at 16:40 +, Joao Pinto wrote:
> help a lot, thank you!
> lets start working then :)
Please read this very useful document first, so that you can avoid
common mistakes ;)
https://www.kernel.org/doc/Documentation/networking/netdev-FAQ.txt
Thanks
On 18-11-2016 16:35, Florian Fainelli wrote:
>
>
> On 11/18/2016 08:31 AM, Joao Pinto wrote:
>> Hi Florian,
>>
>> On 18-11-2016 14:53, Florian Fainelli wrote:
>>> On November 18, 2016 4:28:30 AM PST, Joao Pinto
>>> wrote:
snip (...)
I would also gladly be available to be its mainta
On 11/18/2016 08:31 AM, Joao Pinto wrote:
> Hi Florian,
>
> On 18-11-2016 14:53, Florian Fainelli wrote:
>> On November 18, 2016 4:28:30 AM PST, Joao Pinto
>> wrote:
>>>
>>> Dear all,
>>>
>>> My name is Joao Pinto and I work at Synopsys.
>>> I am a kernel developer with special focus in mainl
Hi Florian,
On 18-11-2016 14:53, Florian Fainelli wrote:
> On November 18, 2016 4:28:30 AM PST, Joao Pinto
> wrote:
>>
>> Dear all,
>>
>> My name is Joao Pinto and I work at Synopsys.
>> I am a kernel developer with special focus in mainline collaboration,
>> both Linux
>> and Buildroot. I was
On November 18, 2016 4:28:30 AM PST, Joao Pinto wrote:
>
>Dear all,
>
>My name is Joao Pinto and I work at Synopsys.
>I am a kernel developer with special focus in mainline collaboration,
>both Linux
>and Buildroot. I was recently named one of the maintainers of the PCIe
>Designware core driver an
interested?
For now we are interesting in improving the synopsys QoS driver under
/nect/ethernet/synopsys. For now the driver structure consists of a single file
called dwc_eth_qos.c, containing synopsys ethernet qos common ops and platform
related stuff.
Our strategy would be:
a) Impl
[The previous e-mail had an error, please consider this one. Thank you.]
Dear all,
My name is Joao Pinto and I work at Synopsys.
I am a kernel developer with special focus in mainline collaboration, both Linux
and Buildroot. I was recently named one of the maintainers of the PCIe
Designware core
Dear all,
My name is Joao Pinto and I work at Synopsys.
I am a kernel developer with special focus in mainline collaboration, both Linux
and Buildroot. I was recently named one of the maintainers of the PCIe
Designware core driver and I was the author of the Designware UFS driver stack.
I am sen
63 matches
Mail list logo
