Re: [rfc] tcp timer update for RSS

2014-07-01 Thread Eggert, Lars
Hi,

[elars@stanley:/home/elars/src] 1 ⌀ grep -r IP_RSSCPUID sys
sys/netinet/in.h:/* 71 - XXX was IP_RSSCPUID - can recycle whenever */
sys/netinet/ip_output.c:case IP_RSSCPUID:

kernel compilation with RSS currently fails, because IP_RSSCPUID is still used 
in ip_output.c.

Lars


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: [rfc] tcp timer update for RSS

2014-07-01 Thread Adrian Chadd
On 1 July 2014 06:14, Eggert, Lars l...@netapp.com wrote:
 Hi,

 [elars@stanley:/home/elars/src] 1 ⌀ grep -r IP_RSSCPUID sys
 sys/netinet/in.h:/* 71 - XXX was IP_RSSCPUID - can recycle whenever */
 sys/netinet/ip_output.c:case IP_RSSCPUID:

 kernel compilation with RSS currently fails, because IP_RSSCPUID is still 
 used in ip_output.c.

I thought I committed a fix to remove that!

I'll go fix that soon. Thanks!


-a
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

Re: [rfc] tcp timer update for RSS

2014-07-01 Thread Adrian Chadd
On 1 July 2014 06:14, Eggert, Lars l...@netapp.com wrote:
 Hi,

 [elars@stanley:/home/elars/src] 1 ⌀ grep -r IP_RSSCPUID sys
 sys/netinet/in.h:/* 71 - XXX was IP_RSSCPUID - can recycle whenever */
 sys/netinet/ip_output.c:case IP_RSSCPUID:

 kernel compilation with RSS currently fails, because IP_RSSCPUID is still 
 used in ip_output.c.

I thought I committed a fix to remove that!

I'll go fix that soon. Thanks!


-a
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

[rfc] IP_BINDMULTI and IP_RSSBUCKETID support

2014-07-01 Thread Adrian Chadd
Hi!

This patch:

http://people.freebsd.org/~adrian/rss/20140701-rss-1.diff

Implements a few things:

* It introduces IP_BINDMULTI, which allows TCP/UDP sockets to be bound
to the same matching address:port. It's intended to be what Linux
SO_REUSEADDR has become except I specifically wanted it to be a
different option.
* .. it only allows the PCBs to be created, it doesn't actually load
balance between multiple sockets like this. That requires a bunch more
work to happen in the general case.

But!

* IP_RSSBUCKETID maps an IPv4 TCP (and later UDP, and much later IPv6)
socket into a specific RSS bucket rather than in the global PCB list.
That way it only receives incoming connections that has to that RSS
bucket ID.

If userland queries the RSS setup (sysctl net.inet.rss) and creates a
worker thread per RSS bucket _AND_ pins it to the correct CPU for the
RSS bucket, all the transmit and receive side will stay on the same
CPU. The lock contention is almost eliminated in that case.

My plan:

* get this into the tree and tested/debugged;
* add IPv4 UDP extensions to RSS;
* teach a couple of popular threaded UDP applications (eg memcached) about this;
* bask in what hopefully will be a good set of benefits;
* work on IP_BINDMULTI support so multiple threads/processes can
listen in the same RSS bucket and get some load balancing;
* add IPv6 support;
* add RSS rebalancing support;
* add multi-socket, multi-NIC RSS awareness.

Thanks!


-a
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org


Re: MTU not regrowing?

2014-07-01 Thread Andrea Venturoli

On 06/25/14 15:23, Andrea Venturoli wrote:

On 06/25/14 02:01, Charles Swiger wrote:


Does ifconfig vlan3 down; ifconfig vlan3 up do any good?
Or that run against the physical NIC?


None of the two.
John was right about the route.

 bye  Thanks
av.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org


Re: MTU not regrowing?

2014-07-01 Thread Andrea Venturoli

On 06/24/14 21:03, John Hay wrote:


Do a route get somehost and see what mtu is returned.


You are right, I see a route with the old, lesser MTU.





You might be able to delete or tweak that route.


How do I do this?
I tried route delete, but it doesn't help.

 bye  Thanks
av.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org


Network Intel X520-SR2 stopping

2014-07-01 Thread Marcelo Gondim

Hi all,

I'm having problems with a 10GbE Intel X520-SR2 interface. After a 
running time, the interface does not send or receive more data. I am 
obliged to make a down and up the interface for it to return to work. 
Have changed the interface, optical cords, optical modules and problem 
continues.


(root@rt01)[~]# netstat -inh
NameMtu Network   Address  Ipkts Ierrs Idrop Opkts 
Oerrs  Coll
igb0   1.5K Link#1  00:1e:67:9b:03:e10 0 0
0 0 0
igb1   1.5K Link#2  00:1e:67:9b:03:e2  19M 0 0  
27M 0 0
igb1  - 177.xx.xxx.0/ 177.xx.xxx.1   15K - -  
14K - -
igb1  - fe80::21e:67f fe80::21e:67ff:fe2 - -
4 - -
igb1  - 2804::cad 2804::cade:b1  14K - -  
12K - -
igb2   1.5K Link#3  00:1e:67:9b:03:e3  17M  5.8K 0  
23M 0 0
igb2  - 177.xx.xxx.40 177.xx.xxx.41  10K - -  
12K - -
igb2  - fe80::21e:67f fe80::21e:67ff:fe0 - -
1 - -
igb2  - 2804::bad 2804::bad:b1f  14K - -  
14K - -
igb3   1.5K Link#4  00:1e:67:9b:03:e4  11K 0 0 
441M 0 0
igb3  - 186.xxx.x.148 186.xxx.x.150  10K - -  
94K - -
igb3  - fe80::21e:67f fe80::21e:67ff:fe0 - -
1 - -
igb4   1.5K Link#5  00:1b:21:7b:ee:6c 5.8G  5.5K 0 
194K 0 0
igb4  - 159.xx.xx.96/ 159.xx.xx.98   63K - -  
18K - -
igb4  - fe80::21b:21f fe80::21b:21ff:fe0 - -
0 - -
igb4  - 2804:xxx: 2804:xxx::ffd  17K - -  
16K - -
igb5   1.5K Link#6  00:1b:21:7b:ee:6d 6.9G  8.0K 0 
9.1G 0 0
igb5  - 64.xxx.xxx.68 64.xxx.xxx.70  28K - - 
5.5M - -
igb5  - fe80::21b:21f fe80::21b:21ff:fe0 - -  
135 - -
igb5  - 2001:xxx:2001 2001:xxx:2001:100  17K - - 
125K - -
igb6   1.5K Link#7  00:1b:21:7b:ee:98 4.3G 0 0 
3.8G 0 0
igb6  - fe80::21b:21f fe80::21b:21ff:fe0 - -
0 - -
igb7   1.5K Link#8  00:1b:21:7b:ee:990 0 0
0 0 0
*ix01.5K Link#9 00:1b:21:89:25:28 -1.5   118  1.5T 
0.1T 0 0*
ix0   - fe80::21b:21f fe80::21b:21ff:fe0 - -
0 - -
ix11.5K Link#10 00:1b:21:89:25:290 0 0
0 0 0
pflog   32K Link#11  0 0 0
0 0 0
pfsyn  1.5K Link#12  0 0 0
0 0 0
lo0 16K Link#1352K 0 0  
52K 0 0
lo0   - ::1/128   ::1  0 - -   
41 - -
lo0   - fe80::1%lo0/6 fe80::1%lo0  0 - -
0 - -
lo0   - 127.0.0.0/8   127.0.0.1  48K - -  
52K - -
disc0   64K Link#14  0 0 0
0 0 0


# uname -a
FreeBSD rt01.xx.xxx.xx 10.0-STABLE FreeBSD 10.0-STABLE #9 r267839: 
Tue Jun 24 21:06:39 BRT 2014 
r...@rt01.xx.xxx.xx:/usr/obj/usr/src/sys/GONDIM  amd64

You have new mail in /var/mail/root

# netstat -ihw 1
input(Total)   output
   packets  errs idrops  bytespackets  errs  bytes colls
  813K 0 0   522M   832K 9   615M 0
  812K 0 0   523M   831K 9   616M 0
  811K 0 0   521M   829K 6   614M 0
  807K 0 0   519M   826K15   615M 0
  794K 0 0   514M   814K 7   610M 0
  799K 0 0   520M   816K 7   612M 0
  804K 0 0   523M   822K14   613M 0
  794K 0 0   518M   813K14   610M 0
  779K 0 0   510M   799K 8   601M 0
  790K 0 0   514M   809K 7   603M 0
  818K 0 0   525M   835K 7   617M 0
  810K 0 0   522M   827K12   614M 0
  794K 0 0   514M   812K13   603M 0
  794K 0 0   518M   813K13   608M 0
  790K 0 0   516M   810K 5   606M 0
  807K 0 0   525M   824K 9   614M 0
  808K 0 0   529M   827K10   619M 0
  805K 0 0   524M   823K 7   614M 0
  804K 0 0   526M   821K 8   615M 0
  799K 0 0   520M   816K 6   612M 0
  803K 0 0   522M   819K11   610M 0

# ifconfig ix0
ix0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

Re: propose a new generic purpose rule option for ipfw

2014-07-01 Thread bycn82
Hi,
Back from the world cup,Let's talk about the topic of U32,

You guys are right, It is almost useless if it can only filter by the 5
tuples.

But in my opinion, It can do regex match based on the pattern. So it can
do something layer7 filtering.

Sure the performance is biggest issue.

Any comments?



On Thu, May 29, 2014 at 10:15 PM, Luigi Rizzo ri...@iet.unipi.it wrote:

 On Thu, May 29, 2014 at 09:48:58PM +0800, bycn82 wrote:
 
 
  -Original Message-
  From: 'Luigi Rizzo' [mailto:ri...@iet.unipi.it]
  Sent: 29 May, 2014 21:10
  To: bycn82
  Cc: 'FreeBSD Net'
  Subject: Re: propose a new generic purpose rule option for ipfw
 
 
 
  On Thu, May 29, 2014 at 08:45:26PM +0800, bycn82 wrote:
 
  ...
 
  
 
   Sure, that is the reason why developers are providing more and more
 rule options. But the my question is do we have enough options to match all
 the fixed position values?
 
 
 
  we do not have an option for fixed position matching.
 
 
 
  Can I say that ???It will be useful when a user come up with a special
 requirement which cannot be fulfilled by any existing rule option.??? Since
 there are so many rule options already. So I don???t know when that special
 requirement will appear. L  that is what you said ???useless???, I accept
 that .

 please re-read what i said below. 'mostly useless' != 'useless',
 and i am ok importing a clean implementation.

  As i said, feel free to submit one and i will be happy to import it if
 the code is clean (btw i am still waiting for fixes to the other 'rate
 limiting' option you sent), but keep in mind that 'fixed position' is
 mostly useless.
 
  Which `rate limiting`, the `Packet per second`?
 
  http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/189720

 ok commented the remaining problems with a separate email.

  More useful options would be one where you express the position as
 
 
 
  '{MAC|VLAN|IP|UDP|TCP|...|PAYLOAD}+offset'
 
 
 
  It is possible,
 
  match position mask value
 
  the mask can be a pattern , then that means it can match multiple
 value at the same time.

 what i wrote is a completely different thing. Never mind.

 cheers
 luigi

 
 
 
  so at least you can adapt to variant headers, or one where you can look
 for a pattern in the entire packet or in a portion of it.

 
 
  cheers
 
  luigi
 
  ___
  freebsd-net@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-net
  To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org


Re: MTU not regrowing?

2014-07-01 Thread John-Mark Gurney
Andrea Venturoli wrote this message on Tue, Jul 01, 2014 at 20:37 +0200:
 On 06/24/14 21:03, John Hay wrote:
 
 Do a route get somehost and see what mtu is returned.
 
 You are right, I see a route with the old, lesser MTU.
 
 
 
 
 You might be able to delete or tweak that route.
 
 How do I do this?
 I tried route delete, but it doesn't help.

route change -mtu XXX routetochange

If you delete all the routes associated w/ the interface, the network
route should be recreated iirc..  Or just run the above change command
on all the necessary routes that have the incorrect mtu..

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 All that I will do, has been done, All that I have, has not.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org


Re: FreeBSD 9 as PPPoE BRAS(mpd 5.7) kernel panic

2014-07-01 Thread Alex Ros

Hi.
So, hint with mpd-down script (with sleep 1) does not help - panic 
after 7 days uptime (rev r267703).

If somebody want to look into last core.txt and vmcore, they are here:
http://pkg.hostelnet.ru/pub/dump/core.txt.9.txt

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org