On Mon, Jun 26, 2023 at 5:58 AM wrote:
>
> Hi guys
>
>
>
> I’m trying to do something similar like in the question here
> (https://lists.freebsd.org/pipermail/freebsd-net/2017-March/047378.html). We
> have Chelsio NICs (T580-LP-CR).
>
>
>
> Our goal is the following:
>
> RSS Queue 0 -> only cont
On 6/27/23 12:47 AM, josef.zahn...@swisscom.com wrote:
We are familiar with «hw.cxgbe.rsrv_noflowq», but as you already stated
it’s only for TX direction, it doesn’t help us at all.
Okay.
Our problem is in fact, that on FreeBSD only CPU0 seems to do the slow
protocol (LACP, CARP,…) stuff and
Hello,
Please try this patch: https://people.freebsd.org/~np/norssq.diff
It adds these sysctls to the driver.
1) hw.cxgbe.rsrv_norssq. This is what you originally asked for.
2) hw.cxgbe.rx_budget. This can be used to force the driver's RX to
yield periodically.
What kind of system (cores, memo
On Mon, Jul 3, 2023 at 8:48 AM wrote:
>
> Sorry for the spam, I do see the values with sysctl now. It seems that
> FreeBSD always loads the if_cxgbe.ko from /boot/kernel/if_cxgbe.ko. So what
> I’ve done is, I renamed the original file and copied the newly compiled
> if_cxgbe.ko from /boot/modul
On 7/10/23 2:36 AM, josef.zahn...@swisscom.com wrote:
Ok we are getting closer to a solution. But I’m a little bit confused,
I’ll try to explain why.
I’ve removed the following sysctl values, as you stated that they are
not official FreeBSD values:
-net.inet.rss.bits="2"
-net.inet.rss.enable
On 8/7/24 7:06 AM, Alan Somers wrote:
I'd like to track the rate of packet loss for outbound packets from
some production servers. Obviously, that's impossible. But I think
that the rate of TCP retransmissions should be a close proxy for
packet loss. Currently I can only observe TCP retransmis
Thanks for the bug report. I added this "t4 sleep test" sleep exactly
for this purpose -- to catch cases where cxgbe(4) thinks it can sleep
but it really can't.
There is no need for a core, the stack has all the info I need.
Regards,
Navdeep
On 03/22/13 12:43, Garrett Cooper wrote:
> Unfort
On Mon, Jun 03, 2013 at 04:04:31AM +, John wrote:
> - Alfred Perlstein's Original Message -
> > This looks like the result of forgetting to include the actual
> > firmware in the kernel config and/or the firmware device itself.
> >
> > Can you check if you've included all the needed ex
On 06/30/13 07:25, Alexander V. Chernikov wrote:
> Hello list!
>
> While experimenting with Chelsio T440-CR (cxgbe) internal firewall, I'm
> getting some kind of unexpected results:
One bit of general advice to begin with: add "hitcnts 1" to all your
filter rules and then you can see how many inc
On 08/05/13 09:15, Luigi Rizzo wrote:
> On Mon, Aug 5, 2013 at 5:46 PM, Adrian Chadd wrote:
>
>> On 5 August 2013 07:59, Bryan Venteicher
>> wrote:
>>
>>> What I've done in my drivers is:
>>> * Lock the core mutex
>>> * Clear IFF_DRV_RUNNING
>>> * Lock/unlock each queue's lock
>>
>> .. and
On 08/13/13 10:29, Julian Elischer wrote:
..
>
> Has anyone done any work on aggregating ACKs, or delaying responding to
> them?
If LRO is enabled on the FreeBSD receiver, ACKs are already aggregated
(a duplicate ACK will result in an immediate flush though.) See tcp_lro_rx.
Regards,
Navdeep
__
On 08/13/13 17:51, Julian Elischer wrote:
> On 8/14/13 1:37 AM, Navdeep Parhar wrote:
>> On 08/13/13 10:29, Julian Elischer wrote:
>> ..
>>> Has anyone done any work on aggregating ACKs, or delaying responding to
>>> them?
>> If LRO is enabled on the FreeBS
On 08/21/13 08:08, Andre Oppermann wrote:
> On 20.08.2013 00:38, Peter Grehan wrote:
>
>> If there's an alternative to M_NOFREE, I'd be more than happy to use
>> that.
>
> Set up your own (*ext_free) function and omit freeing of the mbuf
> itself. Make
> sure to properly track your mbufs to a
On 08/21/13 11:18, Andre Oppermann wrote:
> On 21.08.2013 18:38, Navdeep Parhar wrote:
>> On 08/21/13 08:08, Andre Oppermann wrote:
>>> On 20.08.2013 00:38, Peter Grehan wrote:
>>
>>>
>>>>If there's an alternative to M_NOFREE, I'd be mo
I'd like to add a last-active timestamp to the structure that tracks the
LRO state in a NIC's rx handler. This is r254336 in user/np/cxl_tuning
that will be merged to head if there are no objections.
http://svnweb.freebsd.org/base?view=revision&revision=254336
http://svnweb.freebsd.org/base/user/
On 08/21/13 12:22, Andre Oppermann wrote:
> On 21.08.2013 20:23, Navdeep Parhar wrote:
>> I believe we need an extra patch to get M_NOFREE correct. I've had it
>> forever in some of my internal repos but never committed it upstream
>> (just plain forgot). Since this s
On 08/21/13 13:44, Andre Oppermann wrote:
> On 21.08.2013 21:40, Navdeep Parhar wrote:
>> On 08/21/13 12:22, Andre Oppermann wrote:
>>> On 21.08.2013 20:23, Navdeep Parhar wrote:
>>>> I believe we need an extra patch to get M_NOFREE correct. I've had it
>&g
On 08/21/13 13:59, Andre Oppermann wrote:
> On 21.08.2013 22:52, Navdeep Parhar wrote:
>> It is most flexible to let M_NOFREE work without any assumptions
>> attached (must be M_EXT, etc.) So I still prefer my patch to this. If
>> you don't have any strong prefere
I'd like to merge r254341 from user/np/cxl_tuning to head if there are
no objections. It eliminates a couple of iffy looking constructs in
uipc_mbuf.c
http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/kern/uipc_mbuf.c?r1=254334&r2=254341&diff_format=u
-
Always increment o
I'd like to merge r254342 from user/np/cxl_tuning to head if there are
no objections.
http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/kern/kern_mbuf.c?r1=254334&r2=254342&diff_format=u
http://svnweb.freebsd.org/base/user/np/cxl_tuning/sys/sys/mbuf.h?r1=254334&r2=254342&diff_format=u
---
On 09/06/13 12:10, hiren panchasara wrote:
> tunable_mbinit() in kern_mbuf.c looks like this:
>
> 119 /*
> 120 * The default limit for all mbuf related memory is 1/2 of all
> 121 * available kernel memory (physical or kmem).
> 122 * At most it can be 3/4 of avail
On 09/11/13 07:54, Gleb Smirnoff wrote:
> On Thu, Aug 29, 2013 at 12:57:06PM -0700, Navdeep Parhar wrote:
> N> I'd like to merge r254341 from user/np/cxl_tuning to head if there are
> N> no objections. It eliminates a couple of iffy looking constructs in
> N> uipc
On Tue, Mar 18, 2014 at 11:05:23PM -0700, Julian Elischer wrote:
> On 3/18/14, 8:33 PM, George Neville-Neil wrote:
> >On Mar 7, 2014, at 1:23 , hiren panchasara
> >wrote:
> >
> >>I am thinking of committing following change that includes port number
> >>in "Listen queue overflow" messages.
> I th
On 05/06/14 09:06, Alexander V. Chernikov wrote:
> Hello guys.
> (bootstrapping people involved in previous version of this topic, sorry
> for that)
>
> There were several problem descriptions/discussions on using 9k+ mbufs
> with current allocator in:
> if_em: kern/183381
> cxgbe:
> http://lists.
On 05/23/14 13:52, Julien Charbon wrote:
>
> Hi,
>
> On 23/05/14 14:06, Julien Charbon wrote:
>> On 27/02/14 11:32, Julien Charbon wrote:
>>> On 07/11/13 14:55, Julien Charbon wrote:
On Mon, 04 Nov 2013 22:21:04 +0100, Julien Charbon
wrote:
> I have put technical and how-to-repeat
I'd like to change the netmap global lock from a mutex into a sleepable
shared/exclusive lock. This will allow a driver's nm_register hook
(which is called with the global lock held) to sleep if it has to. I've
casually used pkt-gen after this conversion (patch attached) and the
witness hasn't co
Revision 264905 and 266860 that followed it seem to leak ifaddr
references. ifa_ifwithdstaddr and ifa_ifwithnet both install a
reference on the ifaddr returned to the caller but ip_output does not
release it, eventually leading to a panic when the refcount wraps over
to 0 and the ifaddr is freed w
On 06/20/14 15:20, Alan Somers wrote:
...
>
> Do you have a test case that can reproduce the panic?
>
> -Alan
>
Just run some UDP traffic on head or stable/10 and watch the refcount
leak on the transmitter.
# netperf -H ... -t UDP_STREAM
I see these two do ifa_ref (once per packet).
On 07/08/14 10:46, Hans Petter Selasky wrote:
> Hi,
>
> I'm working on a new feature which will allow TCP connections to be
> timing controlled by the ethernet hardware driver, actually the mlxen
> driver. The main missing piece in the kernel is to allow the mbuf's
> flowid value to be overwritten
I got distracted by some other issues and lost track of this thread.
Can one of you please commit the fix if the discussion has reached a
conclusion? Thanks!
Regards,
Navdeep
On Wed, Jun 25, 2014 at 02:08:35PM +0400, Gleb Smirnoff wrote:
> Alan,
>
> On Tue, Jun 24, 2014 at 08:43:40AM -0600, A
On Wed, Jul 09, 2014 at 04:36:53PM +0200, Hans Petter Selasky wrote:
> On 07/08/14 21:17, Navdeep Parhar wrote:
...
> >
> >I think we need to design this to be as generic as possible. I have
> >quite a bit of code that does this stuff but I haven't pushed it
> >
On 07/11/14 11:03, Bjoern A. Zeeb wrote:
> On 11 Jul 2014, at 17:28 , John Jasem wrote:
>
>> c) the defaults for the cxgbe driver appear to be 8 rx queues, and
>> N tx queues, with N being the number of CPUs detected. For a system
>> running multiple cards, routing or firewalling, does this make
On 07/11/14 10:28, John Jasem wrote:
> In testing two Chelsio T580-CR dual port cards with FreeBSD 10-STABLE,
> I've been able to use a collection of clients to generate approximately
> 1.5-1.6 million TCP packets per second sustained, and routinely hit
> 10GB/s, both measured by netstat -d -b -w1
On Fri, Jul 11, 2014 at 08:58:21PM -0400, John Jasem wrote:
>
> On 07/11/2014 03:32 PM, Navdeep Parhar wrote:
> > On 07/11/14 10:28, John Jasem wrote:
> >> In testing two Chelsio T580-CR dual port cards with FreeBSD 10-STABLE,
> >> I've been able to use
906 259
> 149365 0 90 10
> 0 0 0550M15G 0 0 0 0 0 6 0 0 71837 125
> 157253 0 92 8
> 0 0 0550M15G80 0 0 0 0 6 0 0 73508 179
> 161498 0 92 8
> 0 0 0550M15G 0 0 0 0 0 6 0 0 72673 125
> 159
On 05/27/14 17:32, Luigi Rizzo wrote:
>
>
>
> On Wed, May 28, 2014 at 1:49 AM, Navdeep Parhar wrote:
>
> I'd like to change the netmap global lock from a mutex into a sleepable
> shared/exclusive lock. This will allow a driver's nm_register hook
>
On 07/18/14 00:49, Marcelo Araujo wrote:
> Hello guys,
>
> I made few changes on the lagg(4) patch. Also, I made tests using igb(4),
> ixgbe(4) and em(4); seems everything worked pretty well.
>
> I'm wondering if anyone else could make a review, and what I need to do, to
> see this patch committe
On 07/18/14 19:06, Marcelo Araujo wrote:
>
>
>
> 2014-07-19 2:18 GMT+08:00 Navdeep Parhar <mailto:npar...@gmail.com>>:
>
> On 07/18/14 00:49, Marcelo Araujo wrote:
> > Hello guys,
> >
> > I made few changes on the lagg(4
Looks like there's a case where tcp_detach could return with the inp
lock held. I see an XXXRW comment questioning this possibility, but
we should either add an assertion to verify that the case does not
occur, or unlock the inpcb before returning. Or maybe both?
Regards,
Navdeep
diff -r 35bdf8
On Wed, Feb 1, 2012 at 11:07 AM, wrote:
> Hello!
>
>
> The function always returns an error and remove the chain MBUF for two or
> more generated on the same host.
> If the pre-call m_defrag no error occurs.
> This is normal behavior?
> How to know in advance the maximum size for MBUF that does n
When the kernel decides to respond with a RST to an incoming TCP
segment, it uses its ack# (if valid) as the seq# of the RST. See this
in tcp_dropwithreset:
if (th->th_flags & TH_ACK) {
tcp_respond(tp, mtod(m, void *), th, m, (tcp_seq)0,
th->th_ack, TH_
On 06/13/12 06:30, Andre Oppermann wrote:
On 07.06.2012 22:28, George Neville-Neil wrote:
On Mar 27, 2012, at 18:13 , Navdeep Parhar wrote:
When the kernel decides to respond with a RST to an incoming TCP
segment, it uses its ack# (if valid) as the seq# of the RST. See this
in
On 07/11/12 14:30, g...@freebsd.org wrote:
Howdy,
Does anyone know the reason for this particular check in
ip_output.c?
if (rte != NULL && (rte->rt_flags & (RTF_UP|RTF_HOST))) {
/*
* This case can happen if the user changed the MTU
* of
The following reply was made to PR kern/170713; it has been noted by GNATS.
From: Navdeep Parhar
To: bug-follo...@freebsd.org, yaneg...@gmail.com
Cc:
Subject: Re: kern/170713: [cxgb] Driver must be loaded after boot due to timing
issues checking for kern.ipc.nmb* values set via /boot
Here is a patch that allows each of nmbjumboXX to be set via tunables at
boot-time, independent of nmbclusters. It is useful to be able to set
them this way and avoid problems like the one reported in kern/170713 here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=170713
What do you think? If t
On 08/29/12 10:30, Vijay Singh wrote:
All, I am seeing this warning on my 8.2 based system.
taskqueue_drain with the following non-sleepable locks held:
exclusive rw lle (lle) r = 0 (0xff0014dc9110) locked @ sys/netinet/in.c:1760
KDB: stack backtrace:
kdb_backtrace() at kdb_backtrace+0x3e
_w
The following reply was made to PR kern/172364; it has been noted by GNATS.
From: Navdeep Parhar
To: bug-follo...@freebsd.org, atkin...@gmail.com
Cc:
Subject: Re: kern/172364: [cxbge] cxbge_vlan_config() Fatal trap 12: page
fault while in kernel mode
Date: Fri, 05 Oct 2012 10:41:56 -0700
On Mon, Dec 10, 2012 at 05:37:17PM -0800, Garrett Cooper wrote:
> On Mon, Dec 10, 2012 at 3:21 PM, Adrian Chadd wrote:
> > On 10 December 2012 15:18, wrote:
> >> On Mon, Dec 10, 2012 at 3:10 PM, Adrian Chadd wrote:
> >>> 9216 sounds like a jumbo frame mbuf. So the NIC is writing to an mbuf
> >>
On 12/19/12 11:31, Vijay Singh wrote:
> As it is today, a socket upcall on a listener socket is made with the
> V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn ->
> sowakeup].
>
> I feel that the use of the V_tcbinfo is not consistent in the syncache code.
>
> In syncache_add(), w
On 12/19/12 11:42, Navdeep Parhar wrote:
> On 12/19/12 11:31, Vijay Singh wrote:
>> As it is today, a socket upcall on a listener socket is made with the
>> V_tcbinfo lock held. [tcp_input -> syncache_socket -> sonewconn ->
>> sowakeup].
>>
>> I feel that
On 01/22/13 07:43, Eggert, Lars wrote:
> Hi,
>
> on Linux, various NICs (e.g., ixgbe) support Data Center Bridging. Is this
> also available under FreeBSD? Do *any* NICs support DCB under FreeBSD?
cxgbe(4) hardware supports DCB/DCBX, but I haven't looked at what it
would take to add driver + OS
On Sat, Jun 11, 2011 at 08:07:18PM +0200, K. Macy wrote:
> > I'd really encourage people to look at the code (e.g. the pkt-gen.c
> > program, which is part of the archive) so you can see how easy it
> > is to use.
>
> Provided one has a dedicated interface.
Not necessarily.
The T4 ASIC has more
On Thu, Sep 08, 2011 at 08:34:11AM -0400, John Baldwin wrote:
> On Monday, September 05, 2011 7:21:12 am Ben Hutchings wrote:
> > On Mon, 2011-09-05 at 15:51 +0900, Takuya ASADA wrote:
> > > Hi,
> > >
> > > I implemented Ethernet Flow Director sysctls to ixgbe(4), here's a detail:
> > >
> > > - A
On Fri, Sep 09, 2011 at 01:44:34AM +0100, Ben Hutchings wrote:
> On Thu, 2011-09-08 at 20:13 -0400, George Neville-Neil wrote:
> > On Sep 8, 2011, at 14:49 , Navdeep Parhar wrote:
> >
> > > On Thu, Sep 08, 2011 at 08:34:11AM -0400, John Baldwin wrote:
> > >> O
While stress testing a few systems, I encountered a panic in tcp_drop
due to NULL tp->t_inpcb. tcp_drop had been called by tcp_timer_rexmt.
The problem is that timer_rexmt lets go of the pcbinfo and inp locks and
the inp could be dropped by the time it re-acquires the locks.
The attached patch fi
On Mon, Dec 14, 2009 at 1:30 PM, Jack Goral wrote:
>
> Any idea how to debug problem mentioned in the subject line?
This card is supported in 8-STABLE (r199206 or later). Looks like
you're running
8.0 release. You can grab cxgb(4) code from stable and build + run it
on your system.
Regards,
Na
*ko files.
Send me the output of "pciconf -lv" from your system if it still doesn't
work.
Regards,
Navdeep
> prep adapter failed
> cxgbc0: no msi message to release
> device_attach: cxgbc0 attach returned 19
>
> Any hints?
>
> Thanks,
> Jack Goral
> S
On Mon, Oct 11, 2010 at 12:56:55AM -0400, Bill Desjardins wrote:
> Hi All,
>
> I have a couple Chelsio T304 quad gigabit nics that are going into
> iscsi servers. I got these for the TOE capabilities, but I found in
> the cxgb driver code that it is explicitly disabled for > 2 port nics
> (line 10
On Fri, Jun 12, 2009 at 10:56:31AM +, Bjoern A. Zeeb wrote:
> On Fri, 12 Jun 2009, Pyun YongHyeon wrote:
>
> Hi,
>
> >Yeah, there are no checksum offloading support for IPv6 under
> >FreeBSD so there are no cases the frames are IPv6 when
> >CSUM_IP/CSUM_TCP/CSUM_UDP/CSUM_TSO was set.
>
> The
On Fri, Jun 12, 2009 at 05:38:46PM +, Bjoern A. Zeeb wrote:
> On Fri, 12 Jun 2009, Navdeep Parhar wrote:
>
> >On Fri, Jun 12, 2009 at 10:56:31AM +, Bjoern A. Zeeb wrote:
> >>On Fri, 12 Jun 2009, Pyun YongHyeon wrote:
> >>
> >>Hi,
> >>
>
On 08/20/14 00:34, Hans Petter Selasky wrote:
Hi,
A month has passed since the last e-mail on this topic, and in the
meanwhile some new patches have been created and tested:
Basically the approach has been changed a little bit:
- The creation of hardware transmit rings has been made independen
On 08/20/14 12:25, Hans Petter Selasky wrote:
On 08/20/14 20:44, Navdeep Parhar wrote:
On 08/20/14 00:34, Hans Petter Selasky wrote:
Hi,
A month has passed since the last e-mail on this topic, and in the
meanwhile some new patches have been created and tested:
Basically the approach has been
On 08/25/14 13:39, David Somayajulu wrote:
Hi All,
What is the current support for OFED on FreeBSD ? Are there any drivers which
support either RoCE or iWARP ?
The iw_cxgbe module in sys/dev/cxgbe/iw_cxgbe is an iWARP driver for
cxgbe(4) hardware. The upstream version is kernel verbs only, a
On Fri, Jan 02, 2015 at 06:57:50PM +0300, Alexander V. Chernikov wrote:
> Hello list!
>
> FreeBSD has netmap support for chelsio T5 cards, which is amazing.
> The great thing about implementation is that you can play with
> traffic-generating applications without affecting "main" OS interface,
> w
I see a lot of literal "%s" in netstat's output on head. This on a
freshly built system from today..
# netstat -hdw 1
input(Total) output
packets errs idrops bytespackets errs bytes colls drops
%10s 17 %5s 0 %5s 0 %10s 1.3K
On Tue, Apr 21, 2015 at 12:47:45PM -0700, Scott Larson wrote:
> We're in the process of migrating our network into the future with 40G
> at the core, including our firewall/traffic routers with 40G interfaces. An
> issue which this exposed and threw me for a week turns out to be directly
> rel
On Wed, Apr 29, 2015 at 01:08:00AM -0400, Garrett Wollman wrote:
> < said:
...
> > As far as I know (just from email discussion, never used them myself),
> > you can either stop using jumbo packets or switch to a different net
> > interface that doesn't allocate 9K jumbo mbufs (doing the receives
On Sun, Jun 28, 2015 at 01:18:44PM +0300, Pavel Odintsov wrote:
> Hello, folks!
>
> I'm looking for solution which could do wire speed (56 mpps with
> 64byte packets) for 40GE.
>
> We have tested PF_RING/DPDK on Linux and could not achieve more than
> ~42 mpps and it's not enough for us.
Is this
On 06/29/2015 08:17, Slawa Olhovchenkov wrote:
...
b) custom RSS. Modern NIC have RSS poorly interoperable with packet
analysing: packets from same flow, but different direction placed in
different queue, ...
This is default behavior because the default hash (Toeplitz) is not
symmetrical. The
On Wed, Sep 23, 2015 at 11:15:03PM +0200, Palle Girgensohn wrote:
...
> > By the way Palle could you also run below Dtrace script to see where
> > this tcp_close() in INP_TIMEWAIT comes from:
> >
> > $ cat tcp-close-tw.d
> > fbt::tcp_close:entry
> > /args[0]->t_inpcb->inp_flags & 0x0100/
> > {
The tx errors/drops are almost always due to software queue overflow.
There isn't much that can go wrong once the frame has successfully
been submitted to the hw for tx.
Do you have a lot of PAUSE coming in during the tests where you see
just 31Kpps tx? You can monitor the incoming PAUSE frames w
On 12/26/2017 03:33, Andrey V. Elsukov wrote:
On 26.12.2017 13:22, Harsh Jain wrote:
panic: m_unshare: m0 0xf80020f82600, m 0xf8005d054100 has M_PKTHDR
cpuid = 15
time = 1495578455
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfe044e9bb890
kdb_ba
On 12/27/2017 12:59, Andrey V. Elsukov wrote:
On 27.12.2017 23:09, Navdeep Parhar wrote:
It is not clear to me why it helps. The panic happens on outbound path,
where mbuf should be allocated by network stack and should be writeable.
ip_reass() usually used on inbound path. I think the patch
Done in r329675.
On Mon, 2018-02-19 at 16:41 +0100, Vincenzo Maffione wrote:
> Hello,
> Can anyone please apply the attached patch? It follows up the
> removal of the nkr_slot_flags in the upstream netmap.
> The change fixes compilation issues and has no effect on
> functionality.
>
> Thanks,
On 07/11/18 07:58, Eggert, Lars wrote:
> Hi,
>
> I have netmap working with the T6 cards now.
>
> However, performance is very poor. It seems to take several milliseconds
> after a NIOCTXSYNC ioctl before the tail is updated?
Try changing lazy_tx_credit_flush to 0 on the running kernel with a
d
On Mon, Aug 27, 2018 at 04:19:29PM +0200, Marius Halden wrote:
> Hi,
>
> We have some routers with Chelsio T540-CR NICs using 1Gbps SFPs (1000
> Base-LX IIRC) to connect to our ISPs. After upgrading them to FreeBSD
> 11.2-p2 (BSDRP v1.91) we have run into some issues. When the machines
> are reboo
On 8/28/18 2:35 AM, Marius Halden wrote:
> ...
> media: Ethernet 1000baseSX
> status: active
> supported media:
> media 1000baseSX mediaopt full-duplex,rxpause,txpause
> media 1000baseSX mediaopt full-duplex,rxpause
> media 1000baseSX mediaopt full-duplex,txpaus
On 8/28/18 11:27 AM, Marius Halden wrote:
> On Tue, Aug 28, 2018, at 20:06, Navdeep Parhar wrote:
>> On 8/28/18 2:35 AM, Marius Halden wrote:
>>> ...
>>> media: Ethernet 1000baseSX
>>> status: active
>>> supported media:
>>>
On 8/28/18 12:30 PM, Marius Halden wrote:
> On Tue, Aug 28, 2018, at 20:32, Navdeep Parhar wrote:
>> On 8/28/18 11:27 AM, Marius Halden wrote:
>>> On Tue, Aug 28, 2018, at 20:06, Navdeep Parhar wrote:
>>>> On 8/28/18 2:35 AM, Marius Halden wrote:
>>>>
On 8/30/18 4:21 AM, Marius Halden wrote:
> On Wed, Aug 29, 2018, at 12:22, Marius Halden wrote:
>> On Wed, Aug 29, 2018, at 08:28, Navdeep Parhar wrote:
>>>>>> Provide the output of these commands when the link isn't up:
>>>>>> # ifconfig
On 8/30/18 2:51 PM, Marius Halden wrote:
> On Thu, Aug 30, 2018, at 19:27, Navdeep Parhar wrote:
>> On 8/30/18 4:21 AM, Marius Halden wrote:
>>> I tried to downgrade to a the previous bsdrp version we were running based
>>> on 11.1-RELEASE-p10, but it did not start wor
On 8/30/18 3:14 PM, Navdeep Parhar wrote:
> On 8/30/18 2:51 PM, Marius Halden wrote:
>> On Thu, Aug 30, 2018, at 19:27, Navdeep Parhar wrote:
>>> On 8/30/18 4:21 AM, Marius Halden wrote:
>>>> I tried to downgrade to a the previous bsdrp version we were running based
On 11/22/18 7:30 AM, Lev Serebryakov wrote:
>
> I've obtained Chelsio T3 for my "network lab". It works with cxgb
> driver well, but when I try to use Netmap's pkt-gen on it it crashes
> system immediately with such message:
>
> panic: trying to coalesce 9 packets in to one WR
>
> I've turned a
Fixed in r345701.
On 2019-03-28 22:59, Dustin Marquess wrote:
> On a brand new CURRENT Chelsio (cxl) TOE doesn't work, as loading the
> dependent t4_tom module fails:
>
> If VIMAGE is enabled:
>
> link_elf_obj: symbol vnet_entry_tcp_autorcvbuf_inc undefined
> linker_load_file: /boot/kernel/t4_t
sizeof(struct ether_header)
On 01/08/2016 15:03, Hadi Rezaee wrote:
Hello there,
In some part of my application I need to have the Ethernet header size
(ideally, using sizeof).
Well I guess 'ethhdr' is not exist on FreeBSD, correct ?
According to Linux definition:
struct ethhdr {
unsig
On Wed, Jan 20, 2016 at 03:58:18PM +, Teleric Team wrote:
> I got a Chelsio T5 520-SO with two ports and I get 2 interfaces for it
> port, cxl and ncxl (cxl0 ncxl0 cxl1 ncxl1). Man page mentions cxl is
> for T5, what about ncxl? Should I get both or is something wrong?
> Which one should I use?
On Sat, Jan 23, 2016 at 03:34:27AM -0200, Marcus Cenzatti wrote:
> hello,
>
> I am testing a chelsio t520-so-cr connected to a Intel card with ix(4)
> driver, I can get the ncxl0 interface to transmit at 14Mpps to another
> chelsio or to a Intel card. However I can only get 800Kpps-1Mpps for
> RX
On Sat, Jan 23, 2016 at 03:48:39PM -0200, Marcus Cenzatti wrote:
...
>
> woops, my bad, yes probably we had some drop, with -S and -D now I get
> 1.2Mpps.
Run "netstat -hdw1 -i cxl" on the receiver during your test. Do you
see errs and/or idrops incrementing? The input "packets" counter should
On Sat, Jan 23, 2016 at 03:12:59PM -0200, Marcus Cenzatti wrote:
...
> intel# ./pkt-gen -i ix0 -f tx -d 00:07:43:33:8d:c1 -s 00:07:e9:44:d2:ba
> 267.767848 main [1715] interface is ix0
> 267.767990 extract_ip_range [291] range is 0.0.0.0:90 to 0.0.0.0:90
> 267.768006 extract_ip_range [291] range is
On Sat, Jan 23, 2016 at 04:54:52PM -0200, Marcus Cenzatti wrote:
...
> here is the output for netstat when I pkt-gen -f tx un-throttled (14Mpps):
>
> input(Total) output
>packets errs idrops bytespackets errs bytes colls drops
> 900k 0
On Sat, Jan 23, 2016 at 11:12:28AM -0800, Luigi Rizzo wrote:
> On Sat, Jan 23, 2016 at 10:38 AM, Navdeep Parhar wrote:
> > On Sat, Jan 23, 2016 at 03:48:39PM -0200, Marcus Cenzatti wrote:
> > ...
> >>
> >> woops, my bad, yes probably we had some drop, with
On Sat, Jan 23, 2016 at 08:38:24PM -0800, Adrian Chadd wrote:
> ok, that's a discussion to have with navdeep. That /should/ work.
> Someone may have changed it lately.
Yes this used to work.
>
> Things should behave very well and predictable once you can disable
> cxl0 but not ncxl0. :-P
The pl
On Sat, Jan 23, 2016 at 09:33:32PM -0800, Luigi Rizzo wrote:
> On Sat, Jan 23, 2016 at 8:28 PM, Marcus Cenzatti wrote:
> >
> >
> > On 1/24/2016 at 1:10 AM, "Luigi Rizzo" wrote:
> >>
> >>Thanks for re-running the experiments.
> >>
> >>I am changing the subject so that in the archives it is clear
>
On 04/15/2016 22:38, bazzoola wrote:
> Greetings,
>
> I would like to know where (in the kernel) UDP packets are dropped.
Have you tried netstat -sp udp ? If the drops show up in some counter
there then you can look at the kernel code to see where the counter is
incremented.
Regards,
Navdeep
>
On 04/05/2016 01:30, Steven Crangle wrote:
>
> Hi,
>
>
> I'm looking for a bit of help to track down the reason behind this
> kernel panic, it seems like netmap works fine for the majority of the
> time, but occasionally it will cause the box to kernel panic.
>
>
> The machine is running FreeB
On 04/28/2016 11:13, bazzoola wrote:
> Hi!
>
> Two questions:
>
> (1) Is there a way to know when netmap rx rings overrun? Most NIC
> drivers provide MPC (missed packet count) and sysctl for rx_overrun.
>
> I would like to know if my application is not reading as fast, i.e., no
> frames are bein
On 05/20/2016 09:36, Vijay Singh wrote:
> Hello. I'm looking to have software iWARP working on FreeBSD (kernel mode
> for now). Bernard and his team have an implementation:
> https://github.com/zrlio/softiwarp/tree/master/kernel. It has been released
> under the BSD license. Currently it is written
On Thu, May 26, 2016 at 11:52:45PM -0500, Dustin Marquess wrote:
> After my many issues with ixgbe & ixv, I ended up removing the Intel
> X520s with Chelsio T420-CR and the Intel X710s with Chelsio T520-CR.
> So far so good, except I can't seem to change the MTU away from 1500.
> In fact, ifconfig
On Fri, May 27, 2016 at 12:57:34AM -0400, Garrett Wollman wrote:
> In article
> you
> write:
>
> ># ifconfig -m cxgbe0
> >cxgbe0: flags=8943
>
> ># ifconfig cxgbe0 mtu 9000
> >ifconfig: ioctl SIOCSIFMTU (set mtu): Invalid argument
>
> I believe this device, like many others, does not allow th
On Fri, May 27, 2016 at 12:23:02AM -0700, K. Macy wrote:
> On Thursday, May 26, 2016, Navdeep Parhar wrote:
>
> > On Fri, May 27, 2016 at 12:57:34AM -0400, Garrett Wollman wrote:
> > > In article <
> > cajpshy4vf5ky6guausloorogiquyd2ccrmvxu8x3carqrzx...@
1 - 100 of 144 matches
Mail list logo
