rth
raising the conversation more broadly. The change to add this field is in
https://reviews.freebsd.org/D35339. Drew has tested this isolated change
under load at Netflix and found no impact on performance.
--
John Baldwin
an find at
https://reviews.freebsd.org/D24628
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
aid it wasn't reproducible on some other drivers. I wonder if
other drivers would also provoke this if you just ran them in a detach/attach
loop long enough.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/li
are no other references to the ifp outside of
the thread running detach.
After that you can release device resources, destroy mutexes, free the ifp, etc.
Note that drivers have to be prepared for ether_ifdetach to invoke if_ioctl
(e.g.
when detaching bpf), but of the drivers I've looked a
et the physical address to return.
A fancier version would be to build an sglist describing your buffer and
create an OBJT_SG VM object that you returned from the d_mmap_single
callback, but if you only ever have a single object that is never freed,
the simple version will work fine.
--
jhb accepted this revision.
jhb added a comment.
This revision is now accepted and ready to land.
Thanks!
CHANGES SINCE LAST ACTION
https://reviews.freebsd.org/D19422/new/
REVISION DETAIL
https://reviews.freebsd.org/D19422
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/em
jhb added a comment.
I agree that we can't handle this in ether_ioctl as it varies too much by
real hardware.
INLINE COMMENTS
> if_vxlan.c:90
> + */
> +#define VXLAN_MAX_MTU65435
> +
If it was possible to make this derived from other constants that would be
ideal. has ETHER_MAX_L
jhb accepted this revision.
This revision has a positive review.
REVISION DETAIL
https://reviews.freebsd.org/D9058
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, decui_microsoft.com, jhb
Cc: freebsd-net-list
___
jhb added a comment.
I would suggest rewording the message a bit to something like:
Defer if_up() until after the interface's if_ioctl method is called.
This ensures the interface is initialized by the interface driver before
it can be used by the rest of the system.
REVISI
On Thursday, December 29, 2016 10:02:32 AM Vincenzo Maffione wrote:
> Ok, thanks for the clarification. I change the lock type to MTX_DEF
> (and did a test). I attached the new patch.
Looks good to me, thanks!
> Cheers,
> Vincenzo
>
> 2016-12-29 2:06 GMT+01:00 John Baldwin
_input or m_freem that can't be invoked from
a filter either).
>
> Cheers,
> Vincenzo
>
> 2016-12-28 19:06 GMT+01:00 John Baldwin :
> > Why are you using MTX_SPIN? Changing the lock type to MTX_DEF would seem to
> > be a smaller patch and probably more correct
ision at
https://reviews.freebsd.org/D8955
if you'd like to comment/review.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>>>>> Why is IFNET_WLOCK needed here? It seems like a regression to
> >>>>>>>>> disallow
> >>>>>>>>> sleep on the control path.
> >>>>>>>>>
> >>>>>>>>> Regards,
>
jhb accepted this revision.
REVISION DETAIL
https://reviews.freebsd.org/D5853
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: sepherosa_gmail.com, network, secteam, delphij, glebius, adrian,
honzhan_microsoft.com, howard0su_gmail.com, decui_microsoft.com,
12971 igb1:que 2
> 13032 igb1:que 3
>
> So I guess interrupts are routed correctly after all, but for some reason
> driver takes some 5 times less time to process it on cpus 4-7
> (per-interrupt). Weird.
Are the pps rates the same? It seems like the interrupt rates on igb0
are d
51 5
>11 100086 intr irq271: igb1:que 61 6
>11 100088 intr irq272: igb1:que 71 7
These are clearly what you want, and you can see that the last CPU they
ran on is the CPU you want as well. If you run 'top -SHz' do you see
the thread
that most things
will only check for M_PKTHDR and look for the fields in the first mbuf in
the chain.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to
on how to debug that further are welcome. The box in the
> production, but we can remove traffic during off-peak to run some
> test/debug code on.
Can you get procstat -S output for the interrupt threads? (Usually interrupt
threads are in pid 12, so 'procstat -S 12' would suffice.)
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ach() simpler by avoiding
an extra condition. Please just document it via assertions in tcp_close()
(or is this the assertion that fired and triggered the reported panic? If so,
then you obviously don't need to add it. :-P)
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
ing. Something like this:
vm_mmap(&curproc->p_vmspace->vm_map, &addr, , VM_PROT_READ |
VM_PROT_WRITE, VM_PROT_READ | VM_PROT_WRITE, MAP_SHARED,
OBJT_DEFAULT,
NULL, 0);
It's not great for a true shared memory buffer, but is fine for a one-ti
uffer either via devfs_priv
dtor method, d_close or something else to avoid leaking the kernel mappings.
This has the advantage over the first approach that it will keep the pages
around until all mappings are gone, though once all the kernel mappings are
gone the pages will no longer be wired (though they will be swap-backed).
--
John Baldwin
___
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"
On Thursday, March 12, 2015 04:07:54 PM Hans Petter Selasky wrote:
> On 02/28/15 13:28, John Baldwin wrote:
> > On Friday, February 27, 2015 10:23:10 PM Gleb Smirnoff wrote:
> >> On Thu, Feb 26, 2015 at 08:25:59PM -0800, Adrian Chadd wrote:
> >> A> [snip]
> >>
different patches for
<= 10 (the only thing people are supposed to use in production) vs head due to
if_getcounter() and friends. Also, since 11 won't be out until 2016, that is
far, far too long to wait for more media types. The stuff we need to support
is already shipping in products toda
On Friday, February 27, 2015 10:32:17 AM Adrian Chadd wrote:
> On 27 February 2015 at 10:07, John Baldwin wrote:
> > On Friday, February 27, 2015 10:03:33 AM Adrian Chadd wrote:
> >> Is this also a bug on -9 and -10?
> >
> > Yes. I may merge just the tcp_syncache
t; Thanks, John. That's almost exactly the approach we were considering.
> >
> > - Ryan Q
> > ________
> > From: John Baldwin
> > Sent: Friday, February 27, 2015 10:20 AM
> > To: freebsd-net@freebsd.org
> > Cc: Quattlebaum
tcp_syncache.c portion of that change back to 8.x
without any ill effects and it should fix your problem.
--
John Baldwin
___
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"
>
> Plan B is to steal an unused bit (RFU) to indicate an "extended" media
> type. I then used the variant/subtype field to store the extended type.
> Effectively, the previously unused bit doubles the effective size of the
> subtype field. Given that the previous 5-bit field lasted us 18 years,
> I figured that doubling it would last a while. I also changed the
> SIOGGIFMEDIA ioctl, splitting it for binary compatibility; extended
> types are all mapped to IFM_OTHER (31) using the old interface, but
> are visible using the new one.
>
> With these changes, I modified one driver (vtnet) to use an extended type,
> and the rest of GENERIC is happy. The changes to ifconfig are also fairly
> small. The patch is appended, where email programs will screw it up,
> or at ftp://ftp.karels.net/outgoing/if_media.patch.
>
> The VFAST subtype is a throw-away for testing.
>
> This seems like a reasonably pragmatic change to support the new 40 Gb/s
> media types until someone wants to design an improved but non-backward-
> compatible interface. I think it meets the goal of suitability for
> back-porting; it could be MFCed.
Seems like a reasonable next step to me.
--
John Baldwin
___
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"
jhb added a comment.
This is just "How It Works". You are always supposed to do a callout_drain()
before freeing the storage belonging to a callout. I don't understand how you
are preventing the callout/lock being freed out from under the callout routine
in this version either. Now you can h
jhb added a comment.
To be clear, I'm fine with updating my tests to a different framework, but I
think it's worth discussing what that looked like.
I also had to explicitly drop Giant in my test module handler.
I do think it's probably better to explicitly ask tests to run instead of
having k
jhb added a subscriber: jhb.
jhb added a comment.
Hmm, I do think the idea of a kernel test framework should be discussed in its
own right. I have implemented a much simpler one on my own for unit tests of
locking primitives that you can see here. These worked by declaring tests in
linker set
seem to recall some discussion
> about there being a difference. Perhaps devd is calling something that
> then fiddles with the setting ignoring whats in sysctl.conf ?
Yes, devd is running /etc/rc.d/netif start which probably checks
gateway_enable and sets the sysctl based on that overri
of the file is now changing at a time the Linux
> client doesn't expect, due to changes in ZFS or maybe TOD clock
> resolution. (At one time, the TOD clock was only at a resolution
> of 1sec, so the client wouldn't see the modify time change often.
> I think it is now at a much higher resolution, but would have to
> look at the code/test to be sure.)
No, it's still only a second resolution on FreeBSD by default. You can
make this precise on the NFS server by setting the vfs.timestamp_precision
sysctl to 3. We should probably be using that by default for at least
server-class systems.
--
John Baldwin
___
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"
r" that can be encoded in the existing field
> > for use when the subtype can't fit in the old field. This seems much
> > easier,
> > can be KPI compatible, and will make it much easier to backport drivers.
> > A backport could simply define the new subtypes as &
On Thursday, October 23, 2014 02:12:44 PM Jason Wolfe wrote:
> On Sat, Oct 18, 2014 at 4:42 AM, John Baldwin wrote:
> > On Friday, October 17, 2014 11:32:13 PM Jason Wolfe wrote:
> >> Producing 10G of random traffic against a server with this assertion
> >> added took
he code in your tree is doing?
This is not a NULL tcp timer pointer. Instead, the retransmit timer is being
armed while the persist timer is still armed.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo
t_timers->tt_rexmt) &&
+ delta != 0)
+ panic("scheduling persist with retransmit
active");
break;
case TT_KEEP:
t_callout = &tp->t_timers->tt_kee
On Saturday, October 11, 2014 2:19:19 am Jason Wolfe wrote:
> On Fri, Oct 10, 2014 at 8:53 AM, John Baldwin wrote:
>
> > On Thursday, October 09, 2014 02:31:32 PM Jason Wolfe wrote:
> > > On Wed, Oct 8, 2014 at 12:29 PM, John Baldwin wrote:
> > > > My only oth
On Thursday, October 09, 2014 02:31:32 PM Jason Wolfe wrote:
> On Wed, Oct 8, 2014 at 12:29 PM, John Baldwin wrote:
> > My only other thought is if a direct timeout routine ran for a long time.
> >
> > I just committed a change to current that can let you capture KTR trac
On Wednesday, October 08, 2014 10:56:56 AM Jason Wolfe wrote:
> On Tue, Oct 7, 2014 at 11:28 AM, John Baldwin wrote:
> > On Tuesday, October 07, 2014 2:06:42 pm Jason Wolfe wrote:
> > > Hey John,
> > >
> > > Happy to do this, but the pool of boxes is about
else responded on that thread). I found this again recently in an old
tree and was curious what other folks thought of the idea. I do not have any
workloads I am working with where this is a factor.
--
John Baldwin
___
freebsd-net@freebsd.org maili
On Thursday, October 02, 2014 06:40:21 PM Jason Wolfe wrote:
> On Wed, Sep 10, 2014 at 8:24 AM, John Baldwin wrote:
> > On Monday, September 08, 2014 03:34:02 PM Eric van Gyzen wrote:
> > > On 09/08/2014 15:19, Sean Bruno wrote:
> > > > On Mon, 2014-09-08 at
SOCKBUF_UNLOCK(&so->so_snd);
return (revents);
}
--
John Baldwin
___
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"
onality currently on the lists. I believe gnn@ is looking at that
patch?
--
John Baldwin
___
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"
n net device
> 2. dedicated char device with its own ioctl's
>
> Is there any recommendations on which way is preferred?
I would be inclined towards 2). It is more flexible if you need to add more
custom ioctls in the future.
--
John Baldwin
___
This patch converts a timer in the IPSEC code from using timeout() to using
callout() instead. Can someone test it or review it?
http://people.freebsd.org/~jhb/patches/ipsec_callout.patch
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http
t; details.
> >> This GDB was configured as "amd64-marcel-freebsd"...
> >>
> >> Unread portion of the kernel message buffer:
> >> spin lock 0x812a0400 (callout) held by 0xf800151fe000 (tid
> >> 100003) too
ce creating an IPv4
> socket.
>From looking at the source, it doesn't look like the Linux workaround (using
IP_ADD_MEMBERSHIP on an AF_INET6 socket) will work on FreeBSD. I'm not sure
how hard it would be to fix in6_mcast.c to support IPv4 groups. bms@ might
know.
--
John Baldwin
__
On Tuesday, August 26, 2014 11:05:12 am Alan Somers wrote:
> On Mon, Aug 25, 2014 at 1:52 PM, John Baldwin wrote:
> > On Friday, August 22, 2014 01:34:28 PM Harald Schmalzbauer wrote:
> >> Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime):
> >> > Plea
escription of the problem is within PR.
> >
> > Thanks,
> > Yuri
>
> Hello,
>
> I guess this fix should make it into 10.1.
> Can someone check please?
A fix has to make into HEAD first. I've cc'd Alan who responded to the bug.
Alan, note tha
o->so_snd.sb_cc &&
> + !tcp_timer_active(tp, TT_REXMT) &&
> + !tcp_timer_active(tp, TT_PERSIST)) {
> + tp->t_rxtshift = 0;
> + tcp_setpersist(tp);
> + }
>
> } else {
> /*
> * Persist case, update snd_max but since we are in
>
> Let me know any comments. Thanks,
I think your patch is correct, but please file this as a bug report so we can
hopefully wrangle another person to review this.
--
John Baldwin
___
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"
rea please take a look?
Can't you use IF_ADDR_RLOCK instead of IF_ADDR_WLOCK? Also, strictly speaking
it might be best to use if_maddr_rlock() instead of directly using
IF_ADDR_RLOCK().
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lis
On Saturday, July 19, 2014 1:28:19 pm John Baldwin wrote:
> On Thursday 17 July 2014 19:45:56 Julian Elischer wrote:
> > On 7/15/14, 10:34 PM, John Baldwin wrote:
> > > On Saturday, July 12, 2014 5:14:00 pm Rick Macklem wrote:
> > >> Yonghyeon Pyun wrote:
> > &g
any downsides to this idea. Any good reason why this
> hasn't been done before?
I think it is just a tradeoff between having the timer run at all. However, I
suspect that with high packet rates it probably is cheaper to have the timer
run periodically and reschedule itself if it notices
ferencing data within the old mbuf chain must be recalculated or
made invalid. Return the new mbuf chain on success, NULL on fail-
ure (the mbuf chain is freed in this case). Note: It does not
allocate any mbuf clusters, so len m
On Thursday 17 July 2014 19:45:56 Julian Elischer wrote:
> On 7/15/14, 10:34 PM, John Baldwin wrote:
> > On Saturday, July 12, 2014 5:14:00 pm Rick Macklem wrote:
> >> Yonghyeon Pyun wrote:
> >>> On Fri, Jul 11, 2014 at 09:54:23AM -0400, John Baldwin wrote:
> >
On Saturday, July 12, 2014 5:14:00 pm Rick Macklem wrote:
> Yonghyeon Pyun wrote:
> > On Fri, Jul 11, 2014 at 09:54:23AM -0400, John Baldwin wrote:
> > > On Thursday, July 10, 2014 6:31:43 pm Rick Macklem wrote:
> > > > John Baldwin wrote:
> > > > &g
On Thursday, July 10, 2014 6:31:43 pm Rick Macklem wrote:
> John Baldwin wrote:
> > On Thursday, July 03, 2014 8:51:01 pm Rick Macklem wrote:
> > > Russell L. Carter wrote:
> > > >
> > > >
> > > > On 07/02/14 19:09, Rick Macklem wrote:
> &
s.
ada0 is mounted. but the system is running the old kernel.
> Pulling the 2nd fixed the problem.
>
> What can cause this to happen? Is it a supermicro problem (it's a 5017R-MTF
superserver) or is it something with FreeBSD.
Are you using a software RAID between the two
xpend N=nodelay T=tstmp "
> + "S=sack X=winscale F=fastrec");
> 3) I feel that the header line for o/p (specially 'tcp accepts and
> connects' terminology) can be improved but I do not have a better
> suggestion :-)
4) Should numtok() just be humanize_number? Or rat
missing for a reason?
> >
> > I'm wondering too if there's any good reason not to MFC?
>
> I also don't see any obvious reason.
>
> If nobody objects on -net@, I can do it.
I think this looks fine to merge.
--
John Baldwin
__
remap) {
struct mbuf *m;
- m = m_defrag(*m_headp, M_NOWAIT);
+ m = m_collapse(*m_headp, M_NOWAIT, EM_MAX_SCATTER);
+ if (m == NULL)
+ m = m_defrag(*m_headp, M_NOWAIT);
if (m == NULL) {
On Monday, June 23, 2014 1:12:54 pm Roger Pau Monné wrote:
> On 23/06/14 18:49, Alexander V. Chernikov wrote:
> > On 23.06.2014 20:39, Alexander V. Chernikov wrote:
> >> On 23.06.2014 19:32, John Baldwin wrote:
> >>> On Friday, June 20, 2014 11:25:51 am Roger
ot sure if it would
break things, but I would be tempted to move this even earlier right after it
is removed from the global ifnet list but before the taskqueue_drain, etc.
--
John Baldwin
___
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"
eBSD transfer is good.
>
> The only bad transfer is Windows to FreeBSD. Windows transfer to Mac is
> good. Cant really blame Windows for the poor transfer to FreeBSD then.
> Macbook to FreeBSD is outstanding, cant really blame FreeBSD for poor
> receive performance.
Can you
f anyone is up for the challenge?
QLogic employs one FreeBSD developer already who maintains the qlxgb(4),
qlxge(4), and qlxgbe(4) drivers: David C Somayajulu .
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/
urns void, not an error, so you can't trust the return value.
--
John Baldwin
___
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"
On Thursday, August 29, 2013 11:37:08 am Scott Long wrote:
>
> On Aug 29, 2013, at 7:42 AM, John Baldwin wrote:
>
> > On Saturday, August 24, 2013 10:16:33 am Robert Watson wrote:
> >> There are a number of other places in the kernel where migration to an
>
pport (including an rm_assert).
However, one thing to consider is that rmlocks pin readers to CPUs while the
read lock is held (which rwlocks do not do).
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/f
On Monday, August 05, 2013 6:49:01 am Meny Yossefi wrote:
> John,
>
> Will this be committed to 9.2 as well ?
Yes, I committed it yesterday.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinf
The following reply was made to PR kern/180791; it has been noted by GNATS.
From: John Baldwin
To: bug-follo...@freebsd.org,
shah...@mellanox.com
Cc:
Subject: Re: kern/180791: [ofed] [patch] Kernel crash on ifdown and kldunload
mlxen
Date: Thu, 25 Jul 2013 15:18:06 -0400
Thanks. One note
The following reply was made to PR kern/180430; it has been noted by GNATS.
From: John Baldwin
To: Meny Yossefi
Cc: "bug-follo...@freebsd.org"
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented
packets
Date: Mon, 22 Jul 2013 11:40:08 -0400
On Monday, Jul
The following reply was made to PR kern/180430; it has been noted by GNATS.
From: John Baldwin
To: bug-follo...@freebsd.org,
me...@mellanox.com
Cc:
Subject: Re: kern/180430: [ofed] [patch] Bad UDP checksum calc for fragmented
packets
Date: Fri, 19 Jul 2013 11:13:44 -0400
Oops, my previous
On Wednesday, July 17, 2013 5:23:37 pm Mikolaj Golub wrote:
> On Tue, Jul 16, 2013 at 11:12:46AM -0400, John Baldwin wrote:
> > On Thursday, March 15, 2012 8:07:46 pm Sean Bruno wrote:
> > > On Thu, 2012-03-15 at 16:59 -0700, Sean Bruno wrote:
> > > > Hey, I just
test.c
> >
> > simple compile with gcc -o test test.c and run as normal user.
> >
> > Sean
> >
>
> this is bind() not bind ... :-)
Did the recent commit to HEAD fix this btw?
--
John Baldwin
___
freebsd-net@freebsd.or
mit a slightly cleaned up version (with less debugging)
today, but the patch above will output enough debugging to verify it is working
without requiring a verbose boot.
> John Baldwin wrote:
> > On Monday, June 10, 2013 3:13:11 pm Mr. Clif wrote:
> >> Hi John and Pyun,
>
CSUM_IP)
+ tx_desc->ctrl.srcrb_flags |=
+ cpu_to_be32(MLX4_WQE_CTRL_IP_CSUM);
+ if (mb->m_pkthdr.csum_flags & (CSUM_TCP|CSUM_UDP)) {
+ tx_desc->ctrl.srcrb_flags |=
+ cpu_to_be32(MLX4_WQE_CTRL_TCP_UDP_CSUM);
able bit set and have fixed a few bugs. The updated
patch is at the URL below. I wasn't able to test your specific use case yet
however (of the BIOS using an invalid range).
> Thanks for your help,
> Clif
>
>
> John Baldwin wrote:
> > On Monday, June 10, 2
The following reply was made to PR kern/17; it has been noted by GNATS.
From: John Baldwin
To: bug-follo...@freebsd.org,
shah...@mellanox.com
Cc:
Subject: Re: kern/17: [ofed] [patch] Bug assigning HCA from IB to ETH
Date: Thu, 27 Jun 2013 14:10:42 -0400
Thanks, I think the sysfs fix
e configuration issues?
Do you see memory allocation errors in netstat -m?
Specifically this line:
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
If so, it may be that the IPoIB layer has an mbuf leak. The rest of netstat -
m might be useful here
pture devinfo -u output before
and after.
http://www.freebsd.org/~jhb/patches/pci_isa_enable.patch
--
John Baldwin
___
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"
IB module is missing in /sys/modules.
>
> 1. Where can I find it?
>
> 2. How can I compile ipoib support?
You will have to create one. You should be able to use the existing module
Makefiles as a guide.
--
John Baldwin
_
D$");
#include
#include
-#defineDC_USEIOSPACE
+//#define DC_USEIOSPACE
#include
If this fixes it then I can take this PR as a test case for handling the ISA
enable bit in the PCI-PCI bridge code.
--
John Baldwin
___
freebsd-net@freebs
802.1(q) type header?). Can you
tcpdump on the ib0 interface and see if your pings on ib0.100 show up and if
they have the appropriate headers?
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
ctories at FreeBSD. Wat shall I do?
Have you tried looking for dev.ib.0 sysctls? It looks like the OFED bits in
FreeBSD map Linux sysfs entries to sysctl nodes, but I don't have a box with
IB handy to see what it looks like at runtime.
--
John Baldwin
_
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> >
>
> From reading the source it looks like this is done by attaching a vlan
> interface to the interface. So try:
>
> ifconfig vlan create vlandev ib0 vlan 0xc
>
> This will create a ne
er in
> production and all of them are an indication that something is very wrong
> with the packet or the caller.
Eh, but if the only caller is ether_nh_input() then by definition you know
that m->m_pkthdr.rcvif == ifp.
--
John Baldwin
___
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"
On Thursday, May 23, 2013 5:05:39 pm Guy Helmer wrote:
>
> On Jan 9, 2013, at 2:35 PM, John Baldwin wrote:
>
> > On Tuesday, November 13, 2012 4:40:57 pm Guy Helmer wrote:
> >> To try to completely resolve the race in bpfread(), I have put together
> > these cha
e such
bug was fixed in 8.x here (that is after 8.3):
http://svnweb.freebsd.org/base?view=revision&revision=235553
This may not help with any issues in pf(4), but we had workloads at work (not
involving pf) where this bug could cause boxes to spend 100% CPU in igb
threads.
--
John Baldwin
___
ook that object directly
rather than an fd.
> Laurie
>
> --- On Thu, 4/18/13, John Baldwin wrote:
>
> From: John Baldwin
> Subject: Re: shm_map questions
> To: freebsd-net@freebsd.org
> Cc: "Laurie Jennings"
> Date: Thursday, April 18, 2013, 6:50 AM
>
On Friday, April 19, 2013 4:14:43 pm C. L. Martinez wrote:
> On Friday, April 19, 2013, John Baldwin wrote:
> > On Friday, April 19, 2013 12:32:18 pm C. L. Martinez wrote:
> >> On Friday, April 19, 2013, John Baldwin wrote:
> >> > On Friday, April 19, 2013 3
On Friday, April 19, 2013 12:32:18 pm C. L. Martinez wrote:
> On Friday, April 19, 2013, John Baldwin wrote:
> > On Friday, April 19, 2013 3:11:41 am C. L. Martinez wrote:
> >> Hi all,
> >>
> >> I have a strange problem with my FreeBSD 9.1 (fully patched): I
The following reply was made to PR kern/176446; it has been noted by GNATS.
From: John Baldwin
To: freebsd-net@freebsd.org
Cc: Jack Vogel ,
bug-follo...@freebsd.org
Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving
out-of-order packet process and spurious RST
Date: Fri
The following reply was made to PR kern/176446; it has been noted by GNATS.
From: John Baldwin
To: freebsd-net@freebsd.org
Cc: Jack Vogel ,
bug-follo...@freebsd.org,
Mike Karels
Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving
out-of-order packet process and spurious
E_QUEUE_HUNG;
- if (txr->tx_avail == txr->num_desc) {
+ if (txr->tx_avail == txr->num_desc)
txr->queue_status = IXGBE_QUEUE_IDLE;
- return (FALSE);
- }
-
- return TRUE;
}
/***
*/
- if ((staterr & IXGBE_RXD_STAT_DD) != 0) {
- ixgbe_rearm_queues(adapter, (u64)(1 << que->msix));
- return (TRUE);
- }
-
- return (FALSE);
+ return ((staterr & IXGBE_RXD_STAT_DD) != 0);
}
--
John Baldwin
___
9.1 in the same ESXi host that do not have this problem, but maybe the
> problem is with my sysctl.conf and loader.conf settings:
Which NIC driver are you using?
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mail
es
can shm_open /foo and mmap it and they will all share the same memory.
You could even share a SHM_ANON fd among multiple processes by passing it
across a UNIX domain socket.
Hope this helps.
--
John Baldwin
___
freebsd-net@freebsd.org mailing list
ht
On Tuesday, April 02, 2013 2:33:18 pm Vijay Singh wrote:
> Hi, this is based on the the understanding that the SS_NBIO is a
> socket state, and not a state of the socket buffer.
Committed, thanks!
--
John Baldwin
___
freebsd-net@freebsd.org m
or your help!
Hmm, does the same vlan setup work on a standalone machine?
--
John Baldwin
___
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"
ou need to split the 'struct file' reference count into two different
counts similar to the how we have vref/vrele vs vhold/vdrop for vnodes. The
fget for accept and probably most other system calls should probably be
equivalent
to vhold, whereas things like open/dup (and storing an fd
1 - 100 of 382 matches
Mail list logo
