On Tue, 2017-08-29 at 10:53 -0700, Florian Fainelli wrote:
> On 08/26/2017 11:56 AM, Florian Fainelli wrote:
> >
> >
> > On 08/26/2017 05:47 AM, Eric Dumazet wrote:
> >> On Fri, 2017-08-25 at 21:19 -0700, David Miller wrote:
> >>
> >>> Agreed, but the ARP resolution queue really needs to scale it
On 08/26/2017 11:56 AM, Florian Fainelli wrote:
>
>
> On 08/26/2017 05:47 AM, Eric Dumazet wrote:
>> On Fri, 2017-08-25 at 21:19 -0700, David Miller wrote:
>>
>>> Agreed, but the ARP resolution queue really needs to scale it's backlog
>>> to the physical technology it is attached to.
>> Yes, last
On 08/26/2017 05:47 AM, Eric Dumazet wrote:
> On Fri, 2017-08-25 at 21:19 -0700, David Miller wrote:
>
>> Agreed, but the ARP resolution queue really needs to scale it's backlog
>> to the physical technology it is attached to.
> Yes, last time (in 2011) we increased the old limit of 3 packets :/
On Fri, 2017-08-25 at 21:19 -0700, David Miller wrote:
> Agreed, but the ARP resolution queue really needs to scale it's backlog
> to the physical technology it is attached to.
Yes, last time (in 2011) we increased the old limit of 3 packets :/
We probably should match sysctl_wmem_max so that a s
On Fri, 2017-08-25 at 18:52 -0700, Eric Dumazet wrote:
> I guess we should an SNMP counter for packets dropped in neigh queues.
Info is already there :
cat /proc/net/stat/arp_cache
From: Eric Dumazet
Date: Fri, 25 Aug 2017 20:40:44 -0700
> On Fri, 2017-08-25 at 20:25 -0700, Florian Fainelli wrote:
>
>> It would. Since the call trace involves udp_send_skb() how come we are
>> not returning an error to write(2)? are there other code paths where the
>> neighbor code can do dr
From: Florian Fainelli
Date: Fri, 25 Aug 2017 20:25:26 -0700
> It would. Since the call trace involves udp_send_skb() how come we are
> not returning an error to write(2)? are there other code paths where the
> neighbor code can do drops like these?
Keep in mind that the neighbour code isn't dro
On Fri, 2017-08-25 at 20:25 -0700, Florian Fainelli wrote:
> It would. Since the call trace involves udp_send_skb() how come we are
> not returning an error to write(2)? are there other code paths where the
> neighbor code can do drops like these?
Are you suggesting write(2) should block until AR
On 08/25/2017 06:52 PM, Eric Dumazet wrote:
> On Fri, 2017-08-25 at 18:17 -0700, Florian Fainelli wrote:
>> On 08/25/2017 04:57 PM, Eric Dumazet wrote:
>>> On Fri, 2017-08-25 at 16:18 -0700, Florian Fainelli wrote:
>>>
Eric, are there areas of the stack where we are allowed to drop packets,
On Fri, 2017-08-25 at 18:17 -0700, Florian Fainelli wrote:
> On 08/25/2017 04:57 PM, Eric Dumazet wrote:
> > On Fri, 2017-08-25 at 16:18 -0700, Florian Fainelli wrote:
> >
> >> Eric, are there areas of the stack where we are allowed to drop packets,
> >> not propagate that back to write(2) and als
On 08/25/2017 04:57 PM, Eric Dumazet wrote:
> On Fri, 2017-08-25 at 16:18 -0700, Florian Fainelli wrote:
>
>> Eric, are there areas of the stack where we are allowed to drop packets,
>> not propagate that back to write(2) and also not increment any counter
>> either, or maybe I am not looking wher
On Fri, 2017-08-25 at 16:18 -0700, Florian Fainelli wrote:
> Eric, are there areas of the stack where we are allowed to drop packets,
> not propagate that back to write(2) and also not increment any counter
> either, or maybe I am not looking where I should...
What happens if you increase these s
On 08/23/2017 07:23 PM, Florian Fainelli wrote:
> On 08/23/2017 05:43 PM, Eric Dumazet wrote:
>> On Wed, 2017-08-23 at 17:03 -0700, Florian Fainelli wrote:
>>
>>> Attached is the perf report --stdio of:
>>>
>>> # perf record -a -g -e skb:kfree_skb iperf -c 192.168.1.23 -b 800M -t 60
>>> WARNING: op
On 08/23/2017 05:43 PM, Eric Dumazet wrote:
> On Wed, 2017-08-23 at 17:03 -0700, Florian Fainelli wrote:
>
>> Attached is the perf report --stdio of:
>>
>> # perf record -a -g -e skb:kfree_skb iperf -c 192.168.1.23 -b 800M -t 60
>> WARNING: option -b implies udp testing
>>
On Wed, 2017-08-23 at 17:03 -0700, Florian Fainelli wrote:
> Attached is the perf report --stdio of:
>
> # perf record -a -g -e skb:kfree_skb iperf -c 192.168.1.23 -b 800M -t 60
> WARNING: option -b implies udp testing
>
> Client connec
On Wed, 2017-08-23 at 15:49 -0700, Florian Fainelli wrote:
> On 08/23/2017 03:26 PM, Eric Dumazet wrote:
> > On Wed, 2017-08-23 at 13:02 -0700, Florian Fainelli wrote:
> >> Hi,
> >>
> >> On Broadcom STB chips using bcmsysport.c and bcm_sf2.c we have an out of
> >> band HW mechanism (not using per-f
On 08/23/2017 03:26 PM, Eric Dumazet wrote:
> On Wed, 2017-08-23 at 13:02 -0700, Florian Fainelli wrote:
>> Hi,
>>
>> On Broadcom STB chips using bcmsysport.c and bcm_sf2.c we have an out of
>> band HW mechanism (not using per-flow pause frames) where we can have
>> the integrated network switch ba
On Wed, 2017-08-23 at 13:02 -0700, Florian Fainelli wrote:
> Hi,
>
> On Broadcom STB chips using bcmsysport.c and bcm_sf2.c we have an out of
> band HW mechanism (not using per-flow pause frames) where we can have
> the integrated network switch backpressure the CPU Ethernet controller
> which tra
Hi,
On Broadcom STB chips using bcmsysport.c and bcm_sf2.c we have an out of
band HW mechanism (not using per-flow pause frames) where we can have
the integrated network switch backpressure the CPU Ethernet controller
which translates in completing TX packets interrupts at the appropriate
pace and
19 matches
Mail list logo
