On Fri, May 17, 2019 at 8:57 AM David Laight wrote:
>
> From: Willem de Bruijn
> > Sent: 17 May 2019 04:23
> > On Thu, May 16, 2019 at 8:27 PM Adam Urban wrote:
> > >
> > > And replying to your earlier comment about TTL, yes I think a TTL on
> > > arp_queues would be hugely helpful.
> > >
> > > I
From: Willem de Bruijn
> Sent: 17 May 2019 04:23
> On Thu, May 16, 2019 at 8:27 PM Adam Urban wrote:
> >
> > And replying to your earlier comment about TTL, yes I think a TTL on
> > arp_queues would be hugely helpful.
> >
> > In any environment where you are streaming time-sensitive UDP traffic,
>
On Thu, May 16, 2019 at 8:27 PM Adam Urban wrote:
>
> And replying to your earlier comment about TTL, yes I think a TTL on
> arp_queues would be hugely helpful.
>
> In any environment where you are streaming time-sensitive UDP traffic,
> you really want the kernel to be tuned to immediately drop t
And replying to your earlier comment about TTL, yes I think a TTL on
arp_queues would be hugely helpful.
In any environment where you are streaming time-sensitive UDP traffic,
you really want the kernel to be tuned to immediately drop the
outgoing packet if the destination isn't yet known/in the a
How can I see if there is an active arp queue?
Regarding the qdisc, I don't think we're bumping up against that (at
least not in my tiny bench setup):
tc -s qdisc show
qdisc fq_codel 0: dev eth0 root refcnt 2 limit 10240p flows 1024
quantum 1514 target 5.0ms interval 100.0ms ecn
Sent 925035443 b
On 5/16/19 9:32 AM, Adam Urban wrote:
> Eric, thanks. Increasing wmem_default from 229376 to 2293760 indeed
> makes the issue go away on my test bench. What's a good way to
> determine the optimal value here? I assume this is in bytes and needs
> to be large enough so that the SO_SNDBUF doesn't
Eric, thanks. Increasing wmem_default from 229376 to 2293760 indeed
makes the issue go away on my test bench. What's a good way to
determine the optimal value here? I assume this is in bytes and needs
to be large enough so that the SO_SNDBUF doesn't fill up before the
kernel drops the packets. How
On 5/16/19 9:05 AM, Eric Dumazet wrote:
> We probably should add a ttl on arp queues.
>
> neigh_probe() could do that quite easily.
>
Adam, all you need to do is to increase UDP socket sndbuf.
Either by increasing /proc/sys/net/core/wmem_default
or using setsockopt( ... SO_SNDBUF ... )
On 5/16/19 7:47 AM, Willem de Bruijn wrote:
> On Wed, May 15, 2019 at 3:57 PM Adam Urban wrote:
>>
>> We have an application where we are use sendmsg() to send (lots of)
>> UDP packets to multiple destinations over a single socket, repeatedly,
>> and at a pretty constant rate using IPv4.
>>
>>
/proc/net/stat/ndisc_cache show unresolved_discards appears to show 0
unresolved_discards:
entries,allocs,destroys,hash_grows,lookups,hits,res_failed,rcv_probes_mcast,rcv_probes_ucast,periodic_gc_runs,forced_gc_runs,unresolved_discards,table_fulls
0005,0005,,,,0
On Wed, May 15, 2019 at 3:57 PM Adam Urban wrote:
>
> We have an application where we are use sendmsg() to send (lots of)
> UDP packets to multiple destinations over a single socket, repeatedly,
> and at a pretty constant rate using IPv4.
>
> In some cases, some of these destinations are no longer
11 matches
Mail list logo
