[Differential] [Commented On] D1986: Teach lagg(4) to change MTU
rpokala-panasas.com added a comment. ! In D1986#4, @ae wrote: Just a thought. Imagine two interfaces, one has maximum MTU 2200, another 1500. lagg0 has MTU 1400. Two threads invokes changing MTU in the same time. One wants to change it to 2000, another - to 1500. It is possible, that when both threads will finish its job, one interface will have MTU 1400, but another - 1500. I mean, that such changes should be done exclusively without possibility of races in the ioctl code. Don't the calls to LAGG_RLOCK() / LAGG_RUNLOCK() prevent that by enforcing serialization? REVISION DETAIL https://reviews.freebsd.org/D1986 To: rpokala-panasas.com, rstone Cc: ae, freebsd-net ___ 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
[Differential] [Updated] D1986: Teach lagg(4) to change MTU
rstone added a comment. RLOCK only gets a read lock. You want WLOCK to get a write lock to ensure serialization. REVISION DETAIL https://reviews.freebsd.org/D1986 To: rpokala-panasas.com, rstone Cc: ae, freebsd-net ___ 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
[Differential] [Commented On] D1986: Teach lagg(4) to change MTU
rstone added inline comments. INLINE COMMENTS sys/net/if_lagg.c:1772 style(9) says to not include unnecessary braces (which I personally disagree with, but what can you do?) sys/net/if_lagg.c:1773 style(9): put brackets around the return value: return (0); sys/net/if_lagg.c:1811 I find the flow control here a bit confusing (my first read through, I thought that err2 could be used unitinialized). Given that you have a continue in the if block, I would find it clearer to not have an else here REVISION DETAIL https://reviews.freebsd.org/D1986 To: rpokala-panasas.com, rstone Cc: ae, freebsd-net ___ 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
[Bug 197997] [panic] ng_pppoe sometimes panics with trap 12 when server drops session
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197997 --- Comment #2 from Lev A. Serebryakov l...@freebsd.org --- (In reply to eugen from comment #1) No :( It is NanoBSD system without any space for crashump with autoreboot. Only thing I have is posted panic message from dmesg buffer. I could mot reproduce this now. It happened when my ISP turn off my access for missed payment. Additional complication is, that I place provider link to VLAN with switch (to be able to have 2 links with 1 physical port on router)... -- You are receiving this mail because: You are the assignee for the bug. ___ 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
[Differential] [Changed Subscribers] D1986: Teach lagg(4) to change MTU
ae added a subscriber: ae. ae added a comment. Just a thought. Imagine two interfaces, one has maximum MTU 2200, another 1500. lagg0 has MTU 1400. Two threads invokes changing MTU in the same time. One wants to change it to 2000, another - to 1500. It is possible, that when both threads will finish its job, one interface will have MTU 1400, but another - 1500. I mean, that such changes should be done exclusively without possibility of races in the ioctl code. REVISION DETAIL https://reviews.freebsd.org/D1986 To: rpokala-panasas.com, rstone Cc: ae, freebsd-net ___ 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
[Differential] [Accepted] D1982: Fix return errors in tcp_usrreq.c
jch accepted this revision. This revision is now accepted and ready to land. REVISION DETAIL https://reviews.freebsd.org/D1982 To: harrison.grundy-astrodoggroup.com, gnn, adrian, jch Cc: freebsd-net ___ 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: Intel 82574L (em) [MultiQueue Support Fixes]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/30/15 13:11, Sean Bruno wrote: http://www.intel.com/content/dam/doc/datasheet/82574l-gbe-controller-datasheet.pdf According to 7.1.11, this device does indeed have 2 queues for stuff and or things. So, basic RSS would be possible in something like an Atom box. I note that the em(4) driver intentionally disables this on initialization. I'm up for some science on my new shiny, soon to be router box. Any reason not to default to 1 queue and allow loader.conf to raise it to 2? sean bcc Intel Domination team ___ 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 In general, I figured out the magic dance that is required to enable multiqueue support for em(4). Jeffery's comment about disabling MSI-X was what I was looking for. I've added a review to enable things as a kernel compile option here: https://reviews.freebsd.org/D1994 If the EM_MULTIQUEUE option is enabled, MSI-X defaults to off. This is for testing and needs to be resolved. Perfect for current. EM_MULTIQUEUE is off by default. I've also added missing tuneables to the man page in this review. So, this is a cleanup to being a dev push from my side. Expect more to come in this space. sean -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQF8BAEBCgBmBQJU852ZXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5k0agIAJlkdyqr8N5tALP7c8Eafwg8 w/cFkhcuLwQoCxMQ1gNJpNTKnGWixSalgQTfKdiBvYKGFHtBA5edW32hQSBkus3W yU0RLEdEJyz9F0fMGuxGC1EQRSt54um0B/Ctd7vHEdJtgr+N8ssMsaZVTPioOuEH zXtAId/Gv85UvWH5iElvEph2pEofMw2BQ0XsNUgWwVj5DoAo886reTrsBwqpETjp yqUNxTAtuvS7cK/843nPmpWItg4eYw2YONFOZRVL5CQXFViRHwjf9iSQHelzbcYU suy5Lu5m50ZPGCLgIt8ciWReovDbNkQqSgwc3HbeZ2JRcDMN/Km+nJFeI8eV3+Q= =IbSV -END PGP SIGNATURE- ___ 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
[Differential] [Changed Subscribers] D1986: Teach lagg(4) to change MTU
emaste added a subscriber: emaste. REVISION DETAIL https://reviews.freebsd.org/D1986 To: rpokala-panasas.com, rstone Cc: emaste, ae, freebsd-net ___ 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
[Differential] [Commented On] D1986: Teach lagg(4) to change MTU
ae added a comment. ! In D1986#7, @rstone wrote: RLOCK only gets a read lock. You want WLOCK to get a write lock to ensure serialization. Also we can use another lock in the lagg_ioctl, that will prevent simultaneous MTU changing. REVISION DETAIL https://reviews.freebsd.org/D1986 To: rpokala-panasas.com, rstone Cc: emaste, ae, freebsd-net ___ 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
[Differential] [Changed Subscribers] D1965: Add extended media types to if_media.h and ifconfig
mike-karels.net added a subscriber: mike-karels.net. BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D1965 To: erj, adrian, jfvogel, gnn Cc: mike-karels.net, glebius, freebsd-net ___ 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
[Differential] [Commented On] D1965: Add extended media types to if_media.h and ifconfig
mike-karels.net added a comment. ! In D1965#11, @gnn wrote: BTW Mike Karels was in favor of this in an email thread. He's not yet on phabricator but I'll ask him here as well. Agreed, with minor exceptions. Given the ixl changes, I don't think the vtnet example is worth keeping, and I think that the VFAST/V.fast entry should be removed and other subtypes moved down. BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D1965 To: erj, adrian, jfvogel, gnn Cc: mike-karels.net, glebius, freebsd-net ___ 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
Call for testers: Fix incorrect error codes in connect()
connect(), in both the man page and under POSIX is documented to only return EINVAL for invalid lengths of the namelen parameter, which is a fatal error. As it stands now, it will also return EINVAL when called on TIMEWAIT or DROPPED sockets. The patch at https://reviews.freebsd.org/D1982 changes connect to return EADDRINUSE on time-wait and ECONNREFUSED on dropped. (Different values may make more sense here, POSIX doesn't seem to specify.) If anyone has time to run the patch attached to D1982, it'd be greatly appreciated as I'm trying to find out just how much (if any) software currently depends on the old broken behavior. Any input as to what connect should return in these cases is also appreciated. --- Harrison ___ 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
[Differential] [Updated] D1982: Fix return errors in tcp_usrreq.c
harrison.grundy-astrodoggroup.com added a subscriber: freebsd-net. REVISION DETAIL https://reviews.freebsd.org/D1982 To: harrison.grundy-astrodoggroup.com, jch, gnn, adrian Cc: freebsd-net ___ 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
