sfxge: Do no allow EFSYS_MEM_ALLOC sleep
It solves locking problem when EFSYS_MEM_ALLOC is called in
the context holding a mutex (not allowed to sleep).
E.g. on interface bring up or multicast addresses addition.
sfxge: Do no allow EFSYS_MEM_ALLOC sleep
It solves locking problem when EFSYS_MEM_ALLOC is called in
the context holding a mutex (not allowed to sleep).
E.g. on interface bring up or multicast addresses addition.
Submitted by: Andrew Rybchenko
Sponsored by: Solarflare Communications, Inc.
diff --git a/head/sys/dev/sfxge/common/efsys.h b/head/sys/dev/sfxge/common/efsys.h
--- a/head/sys/dev/sfxge/common/efsys.h
+++ b/head/sys/dev/sfxge/common/efsys.h
@@ -701,7 +701,11 @@
#define EFSYS_KMEM_ALLOC(_esip, _size, _p)\
do {\
(_esip) = (_esip); \
- (_p) = malloc((_size), M_SFXGE, M_WAITOK|M_ZERO); \
+ /* \
+ * The macro is used in non-sleepable contexts, for \
+ * example, holding a mutex.\
+ */ \
+ (_p) = malloc((_size), M_SFXGE, M_NOWAIT|M_ZERO); \
_NOTE(CONSTANTCONDITION) \
} while (B_FALSE)
___
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: Problem with ipfw table add 0.0.0.0/8
On 19.05.2014 17:12, bycn82 wrote:
On 5/19/14 21:00, Alexander V. Chernikov wrote:
On 19.05.2014 11:51, Bill Yuan wrote:
Hi Alex,
Hello Bill!
You guys are chatting here! I agree with you, the table is the place
should
be enhanced, and I am working in this way as described below
1. Support more types.
ip : cidr
ipv4 : same as ip
ipv6 : ip addr v6
mac : mac address
iface : interface name
interface : same as iface
port: it is Alex's idea, I dont know how it works.
Well, actually that's not mine. ipfw implement the following since
long ago:
+ v = ((ipfw_insn_u32 *)cmd)->d[1];
+ switch (v) {
+ case 0:
+ case 1:
+ /* IPv4 src/dst */
+ break;
+ case 2:
+ case 3:
+ /* src/dst port */
+ break;
+ case 4:
+ /* uid/gid */
+ case 5:
+ /* jid */
+ case 6:
+ /* dscp */
+ break;
+ }
I hope you're not using radix to implement mac addresses lookup?
Anyway, it looks like we're doing similar things.
Can you take a look on '[CFT]: ipfw named tables / different
tabletypes' topic and
see how much it conflicts with your changes?
2. Setup the table type
ipfw table type
it will setup the type of the table, and flush the table
3. Get table type
ipfw table type show
4. Add item into the table
ipfw table add
a. get the type of table
b. if the type is not defined yet, that also means the table is new or
empty,
then guess the type based on the
c. format the and insert into the table.
In this way so call "back compatible"
5. how to use table
case 1
ipfw add [line] allow icmp from "table(1)" to "table(2)"
in the ipfw userland command, it should check the table1 and table 2
should
be ipv4 or ipv6 type
case 2
ipfw add allow icmp from any to any MAC "table(3)" "table(4)"
in this case, the table(3) and table(4) should be a table of MAC
addresses.
case 3
ipfw add allow icmp from any to any via table(5)
in this case, the table 5 should be table of interface names.
currently I am working on the mac type. :)
On Sun, May 18, 2014 at 12:47 PM, Jason Hellenthal
wrote:
On May 18, 2014, at 0:12, Julian Elischer wrote:
2) Table type/name can be specified explicitly via one of the
following
commands:
* ipfw table 1 create [type ] [name
"table_name"]
type "ports" would be nice but tricky to do right.
That . . . would be a great addition and have me switching from pf
to ipfw.
Puease do! :-)
___
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"
It is good to know that have company who is working in the same
direction.
and it is really feeling good to have user who is expecting this
feature before implemented. :)
Yup. Named tables (and arbitrary tables) should have been done long time
ago..
You bring up the code first , I can try to add on a patch for the
"mac" type or others , As a newbie here, I am not confident about how
to implement is the best way.
Well, stock radix is slow and consumes a lot of memory per record (more
than 3 cache lines). So it is probably better to implement either array
of configurable item size or/and hash table.
___
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: [Was]: Problem with ipfw table add 0.0.0.0/8
On 19.05.2014 17:38, Dennis Yusupoff wrote: It's not enough, actually. Imagine what you have a table with different networks. If you'll try to find out is an IP belongs to some of that networks from the table, you should to write relatively serious "wrapper" with network range calculations in it. Or can you show differ (easier) way? So it's REALLY usefull to implement that functions "out-of-the-box". Doing "test" function is quite easy. I'll probably do this after finishing new tables code merge. I'm risking to be annoying, but there is a good (from customers point of view) example of tables manipulation in Linux: ipset project (http://ipset.netfilter.org/ipset.man.html) 19.05.2014 17:21, bycn82 пишет: It will be nice to have this feature, but since the `ipfw table list` is existing, so I think this can be implemented outside the ipfw. (personal opinion only ) ___ 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: [Was]: Problem with ipfw table add 0.0.0.0/8
It will e nice to have this utility function > On 21 May, 2014, at 1:32 am, "Alexander V. Chernikov" > wrote: > >> On 19.05.2014 17:38, Dennis Yusupoff wrote: >> It's not enough, actually. >> Imagine what you have a table with different networks. If you'll try to >> find out is an IP belongs to some of that networks from the table, you >> should to write relatively serious "wrapper" with network range >> calculations in it. Or can you show differ (easier) way? >> So it's REALLY usefull to implement that functions "out-of-the-box". > Doing "test" function is quite easy. I'll probably do this after finishing > new tables code merge. >> I'm risking to be annoying, but there is a good (from customers point of >> view) example of tables manipulation in Linux: ipset project >> (http://ipset.netfilter.org/ipset.man.html) >> >> 19.05.2014 17:21, bycn82 пишет: >>> It will be nice to have this feature, >>> but since the `ipfw table list` is existing, >>> so I think this can be implemented outside the ipfw. >>> (personal opinion only ) > > ___ > 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"
[rfc] add non-contiguous CPU ID support to in_rss.c
Hi Robert,
This patch uses CPU_FIRST() and CPU_NEXT() to iterate over the CPU IDs.
Think this is alright?
-a
Index: sys/netinet/in_rss.c
===
--- sys/netinet/in_rss.c (revision 266429)
+++ sys/netinet/in_rss.c (working copy)
@@ -176,6 +176,7 @@
rss_init(__unused void *arg)
{
u_int i;
+ u_int cpuid;
/*
* Validate tunables, coerce to sensible values.
@@ -245,11 +246,12 @@
/*
* Set up initial CPU assignments: round-robin by default.
- *
- * XXXRW: Need a mapping to non-contiguous IDs here.
*/
- for (i = 0; i < rss_buckets; i++)
- rss_table[i].rte_cpu = i % rss_ncpus;
+ cpuid = CPU_FIRST();
+ for (i = 0; i < rss_buckets; i++) {
+ rss_table[i].rte_cpu = cpuid;
+ cpuid = CPU_NEXT(cpuid);
+ }
/*
* Randomize rrs_key.
___
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"
