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
18 matches
Mail list logo
