Netmap instalation error: No rule to make target `/root/netmap/LINUX/e1000/e1000_main.o'

I'm trying to install Netmap, but I got this error: [root@localhost LINUX]# make clean; make make[1]: Entering directory `/usr/src/kernels/3.15.8-200.fc20.x86_64' CLEAN /root/netmap/LINUX/.tmp_versions make[1]: Leaving directory `/usr/src/kernels/3.15.8-200.fc20.x86_64' LIN_VER 30f08 Bui

Re: zero window and persist timer not set

Sweet, I can trigger this at home when doing high connection rate TCP tests. Lemme give this a go tonight/tomorrow and see if it changes the behaviour. Thanks! And yes ,please do file a PR! -a On 11 August 2014 17:05, hiren panchasara wrote: > On Mon, Aug 11, 2014 at 2:20 PM, John Baldwin

Regression test suite for TCP

I was looking for one and found https://wiki.freebsd.org/SummerOfCode2008#TCP.2FIP_regression_test_suite_.28tcptest.29 which is a good start but needs a lot of love (work). Please share if you are aware of any covering basic scenarios. cheers, Hiren ___

Re: zero window and persist timer not set

On Mon, Aug 11, 2014 at 2:20 PM, John Baldwin wrote: > On Wednesday, August 06, 2014 5:25:38 pm Jeremiah Lott wrote: >> Hello, >> >> We've been seeing a problem where a tcp connection is stuck in a zero >> window condition and even though the client has opened more window space, >> our FreeBSD box

Re: zero window and persist timer not set

On Monday 11 August 2014 17:20:18 John Baldwin wrote: > On Wednesday, August 06, 2014 5:25:38 pm Jeremiah Lott wrote: > > Hello, > > > > We've been seeing a problem where a tcp connection is stuck in a zero > > window condition and even though the client has opened more window space, > > our FreeB

Re: A problem on TCP in High RTT Environment.

On Mon, Aug 11, 2014 at 12:59 PM, Michael Tuexen wrote: > On 11 Aug 2014, at 21:40, Eggert, Lars wrote: > >> Hi, >> >> On 2014-8-11, at 21:27, Michael Tuexen >> wrote: >>> On 11 Aug 2014, at 14:12, Eggert, Lars wrote: 544/57/8194 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >>

Re: zero window and persist timer not set

On Wednesday, August 06, 2014 5:25:38 pm Jeremiah Lott wrote: > Hello, > > We've been seeing a problem where a tcp connection is stuck in a zero > window condition and even though the client has opened more window space, > our FreeBSD box never sends any more. After some analysis it appears that

Re: Multicast races on vlan & lagg

On Thursday, July 31, 2014 10:21:22 am Alexander Motin wrote: > Hi. > > Doing some tests on FreeNAS (FreeBSD 9.2+) I hit series of panic during > active interfaces manipulation in some scenarios including multicast and > several vlans on top of lagg. I am not ready to reproduce the full > environm

Re: NFS client READ performance on -current

On Saturday, July 19, 2014 1:28:19 pm John Baldwin wrote: > On Thursday 17 July 2014 19:45:56 Julian Elischer wrote: > > On 7/15/14, 10:34 PM, John Baldwin wrote: > > > On Saturday, July 12, 2014 5:14:00 pm Rick Macklem wrote: > > >> Yonghyeon Pyun wrote: > > >>> On Fri, Jul 11, 2014 at 09:54:23AM

Re: Question about tcp keep-alive timer

On Sunday, August 10, 2014 4:09:55 pm David Bar wrote: > Hi > > > (Forgive me if this topic has been discussed before. I didn't find it in > the archives) > > In tcp_input(), when a packet is received on an established socket the code > re-arms the keep-alive timer, for each packet. > Here: > h

Re: A problem on TCP in High RTT Environment.

On 11 Aug 2014, at 21:40, Eggert, Lars wrote: > Hi, > > On 2014-8-11, at 21:27, Michael Tuexen > wrote: >> On 11 Aug 2014, at 14:12, Eggert, Lars wrote: >>> 544/57/8194 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> I guess the above is the problem. The card wants a lot of mbufs.

Re: A problem on TCP in High RTT Environment.

Hi, On 2014-8-11, at 21:27, Michael Tuexen wrote: > On 11 Aug 2014, at 14:12, Eggert, Lars wrote: >> 544/57/8194 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > I guess the above is the problem. The card wants a lot of mbufs... > So the problem should go away if you increase the numbe

Re: A problem on TCP in High RTT Environment.

On 11 Aug 2014, at 14:12, Eggert, Lars wrote: > On 2014-8-11, at 9:17, Michael Tuexen > wrote: >> Was there any suspicious output provided by netstat -m when the problems >> occur? > > root@laurel:~ # netstat -m > 8186/2179/10365 mbufs in use (current/cache/total) > 8184/1214/9398/2036224 mbu

Re: TCP Rx window auto sizing relies on TCP timestamp option?

On Aug 11, 2014 8:40 PM, "hiren panchasara" wrote: > > On Mon, Aug 11, 2014 at 5:16 AM, Vlad Zolotarov > wrote: > > Hi, I have the most strange question about the TCP Rx window auto sizing > > implementation in a FreeBSD networking stack. > > When I looked at the FreeBSD code (hash > > 9abce0e567

Re: vRSS support on FreeBSD

On 11 August 2014 02:48, Wei Hu wrote: > CC freebsd-net@ for wider discussion. > > Hi Adrian, > > Many thanks for the explanation. I checked the if_igb.c and found the > flowid field was set in the RX side in igb_rxeof(): > > Igb_rxeof() > { > ... > #ifdef RSS > /* XXX

Re: TCP Rx window auto sizing relies on TCP timestamp option?

On Mon, Aug 11, 2014 at 5:16 AM, Vlad Zolotarov wrote: > Hi, I have the most strange question about the TCP Rx window auto sizing > implementation in a FreeBSD networking stack. > When I looked at the FreeBSD code (hash > 9abce0e567c9a5a0520cdd94d5c633c7baf9a184) I noticed that > the mentioned abo

Re: A problem on TCP in High RTT Environment.

Niu Zhixiong wrote this message on Sun, Aug 10, 2014 at 20:27 +0800: > Hi, I am not sure whether my last email is filtered by mailing list. > After disabled tso??? the speed become even poorer??? > This is the packets captures. Plz see google drive. > tcp_with_tso_off.pcapng.gz >

Re: TCP Rx window auto sizing relies on TCP timestamp option?

Vlad Zolotarov wrote this message on Mon, Aug 11, 2014 at 15:16 +0300: > Hi, I have the most strange question about the TCP Rx window auto sizing > implementation in a FreeBSD networking stack. > When I looked at the FreeBSD code (hash > 9abce0e567c9a5a0520cdd94d5c633c7baf9a184) I noticed that >

Re: A problem on TCP in High RTT Environment.

For 60s test at 20Mbps, 200ms delay with hw.igb.num_queues=2 speed is 9.5Mbps. and without it the speed is 9.1Mbps. However, SCTP is 17.10. For 60s test at 20Mbps, 150ms delay with hw.igb.num_queues=2 speed is 11.1Mbps. and without it the speed is 9.92Mbps. However, SCTP is 18.59. For 60s test a

TCP Rx window auto sizing relies on TCP timestamp option?

Hi, I have the most strange question about the TCP Rx window auto sizing implementation in a FreeBSD networking stack. When I looked at the FreeBSD code (hash 9abce0e567c9a5a0520cdd94d5c633c7baf9a184) I noticed that the mentioned above feature will not be "enabled" if there isn't a TCP timestamp

Re: A problem on TCP in High RTT Environment.

On 2014-8-11, at 9:17, Michael Tuexen wrote: > Was there any suspicious output provided by netstat -m when the problems > occur? root@laurel:~ # netstat -m 8186/2179/10365 mbufs in use (current/cache/total) 8184/1214/9398/2036224 mbuf clusters in use (current/cache/total/max) 8184/885 mbuf+clust

Re: A problem on TCP in High RTT Environment.

On 11 Aug 2014, at 09:32, Niu Zhixiong wrote: > Thanks for your reminding. I tried hw.igb.num_queues=2 just now. But, the > throughput is still slow. And When I tested same things in my Virtual > machine-based environment(use Virtio), the throughput is similar(SCTP is 2x > than TCP). So is the

Re: A problem on TCP in High RTT Environment.

On 11 Aug 2014, at 09:31, Niu Zhixiong wrote: > During TCP benchmark. > > root@Freetest0: # netstat -m > 35806/2129/37935 mbufs in use (current/cache/total) > 35251/1037/36288/1011638 mbuf clusters in use (current/cache/total/max) > 35251/1030 mbuf+clusters out of packet secondary zone in use (c

RE: vRSS support on FreeBSD

CC freebsd-net@ for wider discussion. Hi Adrian, Many thanks for the explanation. I checked the if_igb.c and found the flowid field was set in the RX side in igb_rxeof(): Igb_rxeof() { ... #ifdef RSS /* XXX set flowtype once this works right */

[Bugzilla] Commit Needs MFC

Hi, You have a bug in the "Needs MFC" state which has not been touched in 7 or more days. This email serves as a reminder that you may want to MFC this bug or marked it as completed. In the event you have a longer MFC timeout you may update this bug with a comment and I won't remind you again

Re: A problem on TCP in High RTT Environment.

During TCP benchmark. root@Freetest0: # netstat -m 35806/2129/37935 mbufs in use (current/cache/total) 35251/1037/36288/1011638 mbuf clusters in use (current/cache/total/max) 35251/1030 mbuf+clusters out of packet secondary zone in use (current/cache) 0/6/6/505818 4k (page size) jumbo clusters in

Re: A problem on TCP in High RTT Environment.

Thanks for your reminding. I tried hw.igb.num_queues=2 just now. But, the throughput is still slow. And When I tested same things in my Virtual machine-based environment(use Virtio), the throughput is similar(SCTP is 2x than TCP). Regards, Niu Zhixiong －－－ kaia...@gmail.com On Mon,

Re: A problem on TCP in High RTT Environment.

On 11 Aug 2014, at 09:08, Eggert, Lars wrote: > Hi, > > On 2014-8-10, at 5:48, Niu Zhixiong wrote: >> I am using Intel I350-T4 NIC. > > igb driver? > > I've been having weird issues with this driver under 10-RELEASE, too. On one > machine, I had to limit hw.igb.num_queues=2 in order to get a

Re: A problem on TCP in High RTT Environment.

Hi, On 2014-8-10, at 5:48, Niu Zhixiong wrote: > I am using Intel I350-T4 NIC. igb driver? I've been having weird issues with this driver under 10-RELEASE, too. On one machine, I had to limit hw.igb.num_queues=2 in order to get any sort of useful connectivity. On another machine, I had to sev