[Differential] [Request, 12 lines] D1692: sfxge: Change sfxge_ev_qpoll() proto to avoid EVQ pointers array access

arybchik created this revision. arybchik added a reviewer: gnn. arybchik added a subscriber: freebsd-net. arybchik set the repository for this revision to rS (FreeBSD src repository). REVISION SUMMARY It was the only place on data path where sc->evq array is accessed. Sponsored by: Solarf

[Differential] [Request, 195 lines] D1691: sfxge: using 64-bit access for x86-64

arybchik created this revision. arybchik added a reviewer: gnn. arybchik added a subscriber: freebsd-net. arybchik set the repository for this revision to rS (FreeBSD src repository). REVISION SUMMARY Submitted by: Artem V. Andreev Sponsored by: Solarflare Communications, Inc. REVISION D

[Bug 194234] [ixgbe] Update ixgbe to 2.5.27

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194234 Eric Joyner changed: What|Removed |Added Status|New |Closed Resolution|---

[Differential] [Accepted] D1640: Refactor network stack state separate from VSI state

jfvogel accepted this revision. jfvogel added a comment. This revision is now accepted and ready to land. Thanks Ryan, am happier with this. BRANCH review_D1640 REVISION DETAIL https://reviews.freebsd.org/D1640 To: rstone, jfvogel Cc: freebsd-net

[Differential] [Updated, 36 lines] D1657: Allow VFs to run while the PF is admin down

rstone updated this revision to Diff 3467. rstone added a comment. Missed part of the ifx/vsi split CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1657?vs=3463&id=3467 BRANCH review_D1657 REVISION DETAIL https://reviews.freebsd.org/D1657 AFFECTED FILES sys/dev/ixl/if_ixl.c To:

[Differential] [Updated, 118 lines] D1642: Implement PCI SR-IOV method to initialize individual VFs

rstone updated this revision to Diff 3466. rstone added a comment. revert ifx/vsi split CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1642?vs=3395&id=3466 BRANCH review_D1642 REVISION DETAIL https://reviews.freebsd.org/D1642 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ix

[Differential] [Updated, 41 lines] D1655: Add support for GET_STATS VC message

rstone updated this revision to Diff 3465. rstone added a comment. revert ifx/vsi split CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1655?vs=3408&id=3465 BRANCH review_D1655 REVISION DETAIL https://reviews.freebsd.org/D1655 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfv

[Differential] [Updated, 34 lines] D1658: Add sysctls for per-VF hardware counters

rstone updated this revision to Diff 3464. rstone added a comment. Revert ifx/vsi split CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1658?vs=3411&id=3464 BRANCH review_D1658 REVISION DETAIL https://reviews.freebsd.org/D1658 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ix

[Differential] [Updated, 36 lines] D1657: Allow VFs to run while the PF is admin down

rstone updated this revision to Diff 3463. rstone added a comment. Revert ifx/vsi split CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1657?vs=3410&id=3463 BRANCH review_D1657 REVISION DETAIL https://reviews.freebsd.org/D1657 AFFECTED FILES sys/dev/ixl/if_ixl.c To: rstone, jfv

[Differential] [Updated, 161 lines] D1652: Add support for ADD/DEL_ETHER_ADDRESS VC messages

rstone updated this revision to Diff 3462. rstone added a comment. Revert vsi/ifx split CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1652?vs=3405&id=3462 BRANCH review_D1652 REVISION DETAIL https://reviews.freebsd.org/D1652 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ix

[Differential] [Updated, 227 lines] D1641: Implement PCI SR-IOV initialization methods

rstone updated this revision to Diff 3461. rstone added a comment. Undo ifx/vsi split CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1641?vs=3394&id=3461 BRANCH review_D1641 REVISION DETAIL https://reviews.freebsd.org/D1641 AFFECTED FILES sys/dev/ixl/if_ixl.c sys/dev/ixl/ixl.

[Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #14 from Garrett Cooper,425-314-3911 --- (In reply to Eric Joyner from comment #13) I haven't tested the change yet, but thanks for the reminder (I'll verify it this week). If it works, do I have Intel's blessing for committin

Re: is polling still a thing?

On 2015-01-27 18:32:40, Luigi Rizzo wrote: > A netmap-aware NIC has no problem dealing with high PPS rates, > deliver them through the fat pipe HHH to netmap-ipfw in userspace, > which does the filtering and drops the junk. The remaining part > is reinjected through another netmap port into the h

[Bug 194314] [ixgbe] driver makes some dangerous assumptions with struct mbuf sizing with IXGBE_RX_COPY_LEN

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #13 from Eric Joyner --- Has this error gone away with the code change, or did something else happen? -- You are receiving this mail because: You are the assignee for the bug. ___ fr

[Bug 188897] [dc] dc ethernet driver seems to prevent the detection of other NIC chipsets

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188897 --- Comment #9 from c...@eugeneweb.com --- Greetings, I just tried the hint.agp.0.disabled=1 again, and not surprisingly, I got the same results as before. Though I had also forgten what those where. ;-) to wit: Yes it does bring back the r

Re: is polling still a thing?

> On Jan 27, 2015, at 4:08 PM, Antoine Beaupré wrote: > > On 2015-01-27 13:57:20, wishmaster wrote: >> Have you consider to use netmap-based ipfw instead pf in DDoS mitigation? I >> think you should. And without any network ''haks'' like polling. > > My understanding of netmap was that it wasn

Re: is polling still a thing?

On Tue, Jan 27, 2015 at 06:02:46PM -0500, Antoine Beaupr? wrote: > On 2015-01-27 17:39:17, Luigi Rizzo wrote: > > On Tue, Jan 27, 2015 at 05:08:27PM -0500, Antoine Beaupr? wrote: > >> On 2015-01-27 13:57:20, wishmaster wrote: > >> > Have you consider to use netmap-based ipfw instead pf in DDoS > >

Re: is polling still a thing?

On 2015-01-27 17:39:17, Luigi Rizzo wrote: > On Tue, Jan 27, 2015 at 05:08:27PM -0500, Antoine Beaupr? wrote: >> On 2015-01-27 13:57:20, wishmaster wrote: >> > Have you consider to use netmap-based ipfw instead pf in DDoS mitigation? >> > I think you should. And without any network ''haks'' like p

Re: is polling still a thing?

> On Jan 27, 2015, at 2:28 PM, Olivier Cochard-Labbé wrote: > > On Tue, Jan 27, 2015 at 9:15 PM, Michael Sierchio > wrote: > > > On small, embedded computers running ipfw w/kernel nat and device polling > enabled (on em ether adapters), I observed the *reported* sy

Re: Double cleanup in igb_attach

Done, I have also attached the patch in the bug report. -- Thanks, Sreekanth On 1/27/15, 12:54 PM, "Adrian Chadd" wrote: >Hi! > >Sreekanth - this does look like it is valid and needs fixing. Just >file a FreeBSD PR (bugs.freebsd.org/submit/) and we'll assign it to >the intel team

Re: is polling still a thing?

On Tue, Jan 27, 2015 at 05:08:27PM -0500, Antoine Beaupr? wrote: > On 2015-01-27 13:57:20, wishmaster wrote: > > Have you consider to use netmap-based ipfw instead pf in DDoS mitigation? I > > think you should. And without any network ''haks'' like polling. > > My understanding of netmap was that

Re: is polling still a thing?

On 2015-01-27 13:57:20, wishmaster wrote: > Have you consider to use netmap-based ipfw instead pf in DDoS mitigation? I > think you should. And without any network ''haks'' like polling. My understanding of netmap was that it wasn't useful for packet forwarding, because its design is for transmit

Re: Double cleanup in igb_attach

Hi! Sreekanth - this does look like it is valid and needs fixing. Just file a FreeBSD PR (bugs.freebsd.org/submit/) and we'll assign it to the intel team. Thanks! -a On 27 January 2015 at 12:42, Jack Vogel wrote: > Yes, I will look them over. > > Jack > > > On Tue, Jan 27, 2015 at 12:38 PM,

Re: Double cleanup in igb_attach

Yes, I will look them over. Jack On Tue, Jan 27, 2015 at 12:38 PM, Sreekanth Rupavatharam < rupav...@juniper.net> wrote: > Thanks jack, > Now, can you please review these changes? And commit if you deem it > fit? > > Thanks, > > -Sreekanth > > On Jan 27, 2015, at 12:24 PM, "Jack Vogel"

Re: Double cleanup in igb_attach

Thanks jack, Now, can you please review these changes? And commit if you deem it fit? Thanks, -Sreekanth On Jan 27, 2015, at 12:24 PM, "Jack Vogel" mailto:jfvo...@gmail.com>> wrote: E, I am one of those people :) (jack.vo...@intel.com) Jack On Tue, Ja

Re: is polling still a thing?

On Tue, Jan 27, 2015 at 9:15 PM, Michael Sierchio wrote: > > > On small, embedded computers running ipfw w/kernel nat and device polling > enabled (on em ether adapters), I observed the *reported* system load grow > very high. When disabling polling on the interfaces, it went back to > something

Re: Double cleanup in igb_attach

E, I am one of those people :) (jack.vo...@intel.com) Jack On Tue, Jan 27, 2015 at 12:21 PM, Sreekanth Rupavatharam < rupav...@juniper.net> wrote: > Definitely, but I didn't have the contact info of those people. > > Thanks, > > -Sreekanth > > On Jan 27, 2015, at 12:15 PM, "Jack Vogel"

Re: Double cleanup in igb_attach

Definitely, but I didn't have the contact info of those people. Thanks, -Sreekanth On Jan 27, 2015, at 12:15 PM, "Jack Vogel" mailto:jfvo...@gmail.com>> wrote: If you want something committed to an Intel driver, asking Intel might be the courteous thing to do, don't you think? Jack On Tue,

Re: Double cleanup in igb_attach

If you want something committed to an Intel driver, asking Intel might be the courteous thing to do, don't you think? Jack On Tue, Jan 27, 2015 at 11:51 AM, Sreekanth Rupavatharam < rupav...@juniper.net> wrote: > Hiren, > Can you help commit this? > > Index: if_igb.c > > ==

Re: is polling still a thing?

On small, embedded computers running ipfw w/kernel nat and device polling enabled (on em ether adapters), I observed the *reported* system load grow very high. When disabling polling on the interfaces, it went back to something normal. My impression is that the consensus among the core developers

Re: Double cleanup in igb_attach

Hiren, Can you help commit this? Index: if_igb.c === --- if_igb.c (revision 298053) +++ if_igb.c (working copy) @@ -723,7 +723,8 @@ igb_attach(device_t dev) return (0); err_late: - igb_detach(dev); + if(igb_detach(dev) ==

Re: is polling still a thing?

On Tue, Jan 27, 2015 at 7:19 PM, Antoine Beaupré wrote: > On 2015-01-27 13:03:19, Jim Thompson wrote: > > > > > Have you considered FreeBSD 10.1? > > Not yet. What should i expect from the upgrade? We just barely made it > to 9.3 at this point... > Here is an old bench comparing pf improvement s

Re: Double cleanup in igb_attach

On Tue, Jan 27, 2015 at 07:36:17PM +, Sreekanth Rupavatharam wrote: > > > >Seems reasonable to me at the first glance. > > > >We need to call IGB_CORE_LOCK_DESTROY(adapter) before returning though. > > > Not necessary. igb_detach does that. Bah, I read that call inside detach as UNLOCK. Yeah,

Re: Double cleanup in igb_attach

+ Jack On Tue, Jan 27, 2015 at 12:00:19AM +, Sreekanth Rupavatharam wrote: > Apologies if this is not the right forum. In igb_attach function, we have > this code. > err_late: > igb_detach(dev); > igb_free_transmit_structures(adapter); > igb_free_receive_structures(adapter); >

Re: Double cleanup in igb_attach

> >Seems reasonable to me at the first glance. > >We need to call IGB_CORE_LOCK_DESTROY(adapter) before returning though. > Not necessary. igb_detach does that. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-n

Re: is polling still a thing?

Have you consider to use netmap-based ipfw instead pf in DDoS mitigation? I think you should. And without any network ''haks'' like polling. Cheers, Vitaly --- Original Message --- From: "Antoine Beaupré" Date: 27 January 2015, 19:28:55 > (Please CC, as i am not on the list.) > > I wa

[Differential] [Updated, 281 lines] D1640: Refactor network stack state separate from VSI state

rstone updated this revision to Diff 3458. rstone added a comment. Remove the ifx/vsi separation and just refactor out the necessary functions CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D1640?vs=3393&id=3458 BRANCH review_D1640 REVISION DETAIL https://reviews.freebsd.org/D1640

Re: is polling still a thing?

On 2015-01-27 13:03:19, Jim Thompson wrote: >> On Jan 27, 2015, at 11:28 AM, Antoine Beaupré wrote: >> >> (Please CC, as i am not on the list.) >> >> I was surprised to read this article in the pfSense blog: >> >> https://blog.pfsense.org/?p=115 > > That articl

Re: is polling still a thing?

> On Jan 27, 2015, at 11:28 AM, Antoine Beaupré wrote: > > (Please CC, as i am not on the list.) > > I was surprised to read this article in the pfSense blog: > > https://blog.pfsense.org/?p=115 That article is from June 2007. It’s over seven years old. T

is polling still a thing?

(Please CC, as i am not on the list.) I was surprised to read this article in the pfSense blog: https://blog.pfsense.org/?p=115 TLDR: "At this time, polling is not recommended at all." Is that true? I am trying to tweak a Supermicro machine as a router to survive major DDOS attacks on a 1gbps l

ipfw, source-based routing, "forward" action and unknown GW address

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have typical task at hands: two providers, no AS, no real IPv4 addresses in network, IPv4 NAT for both connections. Typical solution for this task is two NATs, "global" rule for outgoing packets and two "forward" rules based on source address a