15.03.2018, 23:08, "sth...@nethelp.no" :
> I have a reproducible problem on 11.1-STABLE where, during a longterm
> iperf3 session, some packets are lost every time ARP is refreshed (every
> net.link.ether.inet.max_age seconds). Checking with tcpdump, I can
> indeed see that the packet loss is happe
On 15.03.2018 23:05, sth...@nethelp.no wrote:
> My idea here is that as long as you have a valid ARP entry, it should
> be possible to refresh the ARP entry *and* continue sending traffic
> (with no packet drops) - i.e. the goal is to completely avoid the
> drops I'm currently seeing on every ARP r
> > I have a reproducible problem on 11.1-STABLE where, during a longterm
> > iperf3 session, some packets are lost every time ARP is refreshed (every
> > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can
> > indeed see that the packet loss is happening as the hosts are doing
> > A
> Can you show your config and stats after the test?
> # sysctl net.link.ether
> # netstat -sp arp
> # netstat -sp ip
> # netstat -sp udp
OK, below is the output from these commands, run on the iperf3 sender,
from before and after one test run. I ran the test for 370 seconds,
and had 3 periods of
> > > I have a reproducible problem on 11.1-STABLE where, during a longterm
> > > iperf3 session, some packets are lost every time ARP is refreshed (every
> > > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can
> > > indeed see that the packet loss is happening as the hosts are doi
> > > > I have a reproducible problem on 11.1-STABLE where, during a longterm
> > > > iperf3 session, some packets are lost every time ARP is refreshed (every
> > > > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can
> > > > indeed see that the packet loss is happening as the hosts
On 16.03.2018 14:47, sth...@nethelp.no wrote:
>> And thank you for that suggestion! The packet loss during ARP refresh
>> (of the destination address connected to the output interface) does
>> *not* happen when the box is forwarding! It only happens with locally
>> generated traffic.
>
> Checking
> >> And thank you for that suggestion! The packet loss during ARP refresh
> >> (of the destination address connected to the output interface) does
> >> *not* happen when the box is forwarding! It only happens with locally
> >> generated traffic.
> >
> > Checking once per second with "arp -n " I c
On 16.03.2018 16:47, sth...@nethelp.no wrote:
>> Can you test this patch? I did not tested it, but I think it should fix
>> this issue.
>
> Looks like this is a patch against HEAD. I don't have any boxes
> running HEAD, but I can get one installed and test the patch this
> weekend (unless you want
I am having difficulties with netmap over top of ixgbevf when attempting to use
a large MTU (say 9000 bytes).
Does the ixgbevf driver use 2048 byte buffers for RX regardless of the MTU or
netmap buffer size?
I can send large frames just fine but inbound frames are passed via netmap as
2048 byt
Sorry, I should have added, this is LINUX if it matters.
Joe Buehler wrote:
> I am having difficulties with netmap over top of ixgbevf when attempting to
> use a large MTU (say 9000 bytes).
>
> Does the ixgbevf driver use 2048 byte buffers for RX regardless of the MTU or
> netmap buffer size?
>
11 matches
Mail list logo
