Re: Netmap: head vs cur vs tail?

2014-10-17 Thread Matthew P. Grosvenor
Thanks! This has tons more info. I'll have a read. --- Sent from my phone, sorry about the typos. > On 17 Oct 2014, at 18:27, Luigi Rizzo wrote: > > > >> On Fri, Oct 17, 2014 at 9:55 AM, Matthew P. Grosvenor >> wrote: >> Hi all, >> I’m trying to understand how to use the netmap fr

Re: ixgbe(4) spin lock held too long

2014-10-17 Thread Adrian Chadd
Hm, is this the bug that was just fixed in -HEAD? I saw this similar bug on -HEAD with lots of quick connections and reused ports. It ended up deferencing a NULL tcp timer pointer from the inpcb. Is that what the code in your tree is doing? -a On 17 October 2014 23:32, Jason Wolfe wrote: > On

Re: ixgbe(4) spin lock held too long

2014-10-17 Thread Jason Wolfe
On Thu, Oct 16, 2014 at 12:23 PM, John Baldwin wrote: > > > I looked at the other trace and I don't think it disagrees with my previous > theory. I do have more KTR patches to log when we spin on locks which would > really confirm this, but I haven't tested those fully on HEAD yet. > > However, I

Re: ixgbe(4) spin lock held too long

2014-10-17 Thread Jason Wolfe
On Thu, Oct 16, 2014 at 12:23 PM, John Baldwin wrote: > > > I looked at the other trace and I don't think it disagrees with my previous > theory. I do have more KTR patches to log when we spin on locks which would > really confirm this, but I haven't tested those fully on HEAD yet. > > However, I

Re: IPv6 stacks responds to all node link local multicast NS

2014-10-17 Thread Hiroki Sato
prabhakar lakhera wrote in : pr> This probably is more of a compliance issue (or may be not as the NS pr> receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 does pr> not talk about it). pr> pr> The neighbor solicitation message format says this: pr> pr> http://tools.ietf.org

Re: Adding IP_PEERCRED?

2014-10-17 Thread Adrian Chadd
Sure! Put together a patch and let's review it. -a On 17 October 2014 17:02, Nicolas Braud-Santoni wrote: > Hello, > > I would like to enquire about the possibility of adding an IP_PEERCRED > socket option to ip(4) which would be similar to LOCAL_PEERCRED for > unix(4). > > Such a option, when

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

2014-10-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #11 from Garrett Cooper --- (In reply to Garrett Cooper from comment #10) ... > - What architectures is this driver supported on? What I was really driving at with this question is "What architectures does Intel support this dr

Adding IP_PEERCRED?

2014-10-17 Thread Nicolas Braud-Santoni
Hello, I would like to enquire about the possibility of adding an IP_PEERCRED socket option to ip(4) which would be similar to LOCAL_PEERCRED for unix(4). Such a option, when requested via getsockopt(2) on a not-connectionless IP (v4 or v6) socket, would either - return credentials of the remote

Re: IPv6 stacks responds to all node link local multicast NS

2014-10-17 Thread Zaphod Beeblebrox
Urm ... question: is NS how, then, a client should be getting an IP over PPP? I have an l2tp server configured with mpd ... and I've noticed that mpd will allow me to turn on ipv6, but it won't assign addresses like ipv4. On Fri, Oct 17, 2014 at 2:28 PM, prabhakar lakhera < prabhakar.lakh...@gmai

[Bug 189404] [msk] msk0:watch dog time out

2014-10-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189404 Mark Linimon changed: What|Removed |Added Component|amd64 |kern Assignee|freebsd-am.

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

2014-10-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194314 --- Comment #10 from Garrett Cooper --- (In reply to Eric Joyner from comment #8) > So it sounds like we may just need to change IXGBE_RX_COPY_LEN from a fixed > value of 160 to something that's calculated based on the length of struct > m_

Re: Enabling VIMAGE by default for FreeBSD 11?

2014-10-17 Thread Julian Elischer
On 10/17/14, 7:51 PM, Marko Zec wrote: On Fri, 17 Oct 2014 13:37:37 +0200 Marius Strobl wrote: On Wed, Oct 15, 2014 at 04:27:28PM -0700, Craig Rodrigues wrote: On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: It was for a while in 9.2, but we removed it from 10.0 and later due to stabili

IPv6 stacks responds to all node link local multicast NS

2014-10-17 Thread prabhakar lakhera
This probably is more of a compliance issue (or may be not as the NS receipt section of RFC 4861 http://tools.ietf.org/html/rfc4861#page-62 does not talk about it). The neighbor solicitation message format says this: http://tools.ietf.org/html/rfc4861#page-22 Destination Address

Re: Netmap: head vs cur vs tail?

2014-10-17 Thread Luigi Rizzo
On Fri, Oct 17, 2014 at 9:55 AM, Matthew P. Grosvenor < matthew.grosve...@cl.cam.ac.uk> wrote: > Hi all, > I’m trying to understand how to use the netmap framework, specifically how > the head, tail and current “pointers” interact with each other. > > Looking in man NETMAP(4) ( > http://www.freebs

Netmap: head vs cur vs tail?

2014-10-17 Thread Matthew P. Grosvenor
Hi all, I’m trying to understand how to use the netmap framework, specifically how the head, tail and current “pointers” interact with each other. Looking in man NETMAP(4) (http://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4) under data structures, struct netmap_ring it says: " contai

Re: Enabling VIMAGE by default for FreeBSD 11?

2014-10-17 Thread Marko Zec
On Fri, 17 Oct 2014 13:37:37 +0200 Marius Strobl wrote: > On Wed, Oct 15, 2014 at 04:27:28PM -0700, Craig Rodrigues wrote: > > On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: > > > > > > > > It was for a while in 9.2, but we removed it from 10.0 and later > > > due to stability issues we kep

Re: Enabling VIMAGE by default for FreeBSD 11?

2014-10-17 Thread Marius Strobl
On Wed, Oct 15, 2014 at 04:27:28PM -0700, Craig Rodrigues wrote: > On Sun, Oct 12, 2014 at 6:35 AM, Kris Moore wrote: > > > > > It was for a while in 9.2, but we removed it from 10.0 and later due to > > stability issues we kept getting reports about. Haven't tried it since > > then, dont know if