HEAD/11 is the FreeBSD version.
Your question is about netmap on Linux, so this is the wrong mailing list.
You should open an issue on the official netmap
https://github.com/luigirizzo/netmap/issues
Cheers
Vincenzo
2017-12-02 13:20 GMT+01:00 Joe Buehler :
> K. Macy wrote:
>
> >
K. Macy wrote:
> HEAD or 11?
I'm not quite sure what the question means but there is this in the
netmap code:
./net/netmap.h:42:#define NETMAP_API 11 /* current API
version */
LINUX kernels nowadays can timestamp frames when they arrive from the
NIC. I made a
HEAD or 11?
On Thu, Nov 30, 2017 at 13:03 Joe Buehler wrote:
> I am using the LINUX 4.4.86 realtime kernel patch with netmap and the
> ixgbevf driver (SRIOV in a VM) and having some serious RX latency issues.
>
> The ixbgevf driver built by the netmap build against the kernel sourc
Hi,
I am currently playing with lb app in netmap. Every time I kill/close it,
the app hangs for some time and does not end immediately. In syslogs I am
getting:
'
Netmap_do_unregif deleting last instance for myapp{1
Netmap_do_deref active=5
Netnap_obj_free ouch, double free on b
Here is what I start seeing in dmesg when I attempt to use the 4.2.1
ixgbevf driver as modified for netmap.
Joe Buehler
[ 136.607019] 343.712201 [ 189] ixgbe_netmap_configure_srrctl not supported
[ 136.610020] 343.715203 [ 189] ixgbe_netmap_configure_srrctl not supported
[ 136.796698] ixgbevf
I am using the LINUX 4.4.86 realtime kernel patch with netmap and the
ixgbevf driver (SRIOV in a VM) and having some serious RX latency issues.
The ixbgevf driver built by the netmap build against the kernel source
does not work. I haven't tried to debug it -- the netmap driver
complains
Vincenzo Maffione's Nachricht vom 21.11.2017 09:39
> >> (localtime):
> >> …
> >> >
> >> > If this is the case, although you are allowed to do that, I don't
> think
> >> > it's a convenient way to use netmap.
> >> > Si
; Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39
>> (localtime):
>> …
>> >
>> > If this is the case, although you are allowed to do that, I don't think
>> > it's a convenient way to use netmap.
>> > Sin
…
> >
> > If this is the case, although you are allowed to do that, I don't think
> > it's a convenient way to use netmap.
> > Since VLAN interfaces like vlan0 do not have (and cannot have) native
> > netmap support, you are falling back to
2017-11-21 21:48 GMT+01:00 Harry Schmalzbauer :
> Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39 (localtime):
> …
> >
> > If this is the case, although you are allowed to do that, I don't think
> > it's a convenient way to use netmap.
> >
Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39 (localtime):
…
>
> If this is the case, although you are allowed to do that, I don't think
> it's a convenient way to use netmap.
> Since VLAN interfaces like vlan0 do not have (and cannot have) native
> n
ration
> (ring size, number of rings, etc.) while netmap was active and doing so
> you triggered
> some hidden bug.
The host was completely untouched when these lockups occured in late
test phase. Only guests were configured/utilized.
No previous (short term stress) test had caused any pr
It may be that your is not a deadlock but some kind of crash. Enabling
debugging features would probably help (e.g. to get a stack trace).
Maybe your lockup/crash happened because you did some reconfiguration (ring
size, number of rings, etc.) while netmap was active and doing so you
triggered
are allowed to do that, I don't think
> it's a convenient way to use netmap.
> Since VLAN interfaces like vlan0 do not have (and cannot have) native
> netmap support, you are falling back to emulated netmap adapters (which
> are probably buggy on FreeBSD, specially whe
s the case, although you are allowed to do that, I don't think
it's a convenient way to use netmap.
Since VLAN interfaces like vlan0 do not have (and cannot have) native
netmap support, you are falling back to emulated netmap adapters (which are
probably buggy on FreeBSD, specially whe
Hi,
Netmap version (tag v11.3 vs master) should be unrelated.
Are you using ixgbe? In this case it may depend on the ixgbe driver version
that netmap is using for patching.
On github master you can change the version by modifying the ixgbe line in
LINUX/default-config.mak.in_.
Valid versions are
Hi Luigi,
Thanks!
I was using the most recent netmap on Github and I believe the tail pointer
only moves forward when there are less than half of the total slots
available in the netmap ring.
Then I switch to the version of v11.3
<https://github.com/luigirizzo/netmap/tree/v11.3>, it beha
11:52 AM, Vincenzo Maffione
> wrote:
>
>> Hi,
>> This is actually a limitation of the netmap API: ring->tail is exposed
>> to the user so that it knows it can use the slots in the range
>> "[ring->head..ring->tail[" for new transmissions (note
configurable feature?
Best,
Xiaoye
On Fri, Oct 27, 2017 at 11:52 AM, Vincenzo Maffione
wrote:
> Hi,
> This is actually a limitation of the netmap API: ring->tail is exposed
> to the user so that it knows it can use the slots in the range
> "[ring->head..ring->tail[" f
point, the complete netmap subsystem seems to deadlock:
'vale-ctl' hangs uninteruptable.
Trying to attach a tcpdump to a vale switch also hands uninteruptable.
Stoping (shuting down from inside) bhyve guests works up to the point
where the vale port should be destroyed.
I could continue the l
On Sat, Nov 11, 2017 at 8:30 PM, K. Macy wrote:
> On Tue, Nov 7, 2017 at 9:32 AM, Vincenzo Maffione
> wrote:
>> Hi,
>> In general netmap adapters (i.e. netmap ports) may support NS_MOREFRAG.
>> But in practice this is mainly supported on VALE ports.
>> So if you
On Tue, Nov 7, 2017 at 9:32 AM, Vincenzo Maffione wrote:
> Hi,
> In general netmap adapters (i.e. netmap ports) may support NS_MOREFRAG.
> But in practice this is mainly supported on VALE ports.
> So if you don't want to add the missing support by yourself you can simply
&g
I see, but it seems there is a bug anyway. Feel free to open a bug report
here https://github.com/luigirizzo/netmap/issues if you wish.
2017-11-07 21:13 GMT+01:00 Joe Buehler :
> Decreasing buf_num to 32768 eliminated the allocation failure.
>
> Joe Buehler
>
--
Vince
Decreasing buf_num to 32768 eliminated the allocation failure.
Joe Buehler
___
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"
Vincenzo Maffione wrote:
> In general netmap adapters (i.e. netmap ports) may support
> NS_MOREFRAG. But in practice this is mainly supported on VALE ports.
> So if you don't want to add the missing support by yourself you can
> simply change the netmap buffer size by
Hi,
In general netmap adapters (i.e. netmap ports) may support NS_MOREFRAG.
But in practice this is mainly supported on VALE ports.
So if you don't want to add the missing support by yourself you can simply
change the netmap buffer size by tuning the sysctl dev.netmap.buf_size, and
increa
I understand. My point was simply to make sure your performance problems
here are not netmap's fault.
Cheers,
Vincenzo
2017-11-07 18:25 GMT+01:00 Joe Buehler :
> I believe the frame drop is due to the nature of my KVM setup. There
> are large latencies in processing incoming frames due to the
Does NS_MOREFRAG work when using netmap with network adaptors (e.g.
virtio_net)?
I need to send and receive large frames -- 9600 bytes -- but the netmap
buffer size is only 2048.
Joe Buehler
___
freebsd-net@freebsd.org mailing list
https
I believe the frame drop is due to the nature of my KVM setup. There
are large latencies in processing incoming frames due to the vagaries of
the LINUX kernel. Moving to the RT kernel helped, host tuning is also
needed to eliminate large latencies in processing frames. There is good
information
Hi Vincenzo,
thanks a lot for your help. I tried it this morning and worked like a charm!
Cheers
Santi
On 02/11/17 21:31, Vincenzo Maffione wrote:
> Hi,
> With vmx driver netmap will use the emulated netmap adapter. On freebsd
> netmap still does not have a way to see how many
Hi,
With vmx driver netmap will use the emulated netmap adapter. On freebsd
netmap still does not have a way to see how many rings an interface has. So
by default will assume 1 tx/rx rings couple for emulated adapter. You can
however change this by sysctl dev.netmap.generic_rings.
Cheers
Hi list, hope you guys are doing well.
I have a basic question. Do you know if multiple TX queues are
supported for vmx + netmap ?
Basically I'm using pkt-gen to generate bulk traffic @10Gbps and its OK
with packet size >~1000b.
For small packets I should use multiple cores/process
Vincenzo Maffione wrote:
> You need to figure out who is dropping the RX packets and why. This
> seems to happen before the packets really make their way to the
> virtio-net RX ring. So it must be some queue overflow in the macvtap or
> your ixgbe device.
I cranked up the qlen on macvtap1 (100,00
Hi,
This is actually a limitation of the netmap API: ring->tail is exposed to
the user so that it knows it can use the slots in the range
"[ring->head..ring->tail[" for new transmissions (note that head is
included, tail excluded, to prevent wraparound). However, there is no
etting a lot of RX frame drop.
> Based on counters, the TX frames are making it to the external loopback
> device, about 1 million frames/sec, which is looping them all back, but
> the macvtap interface on the host that feeds into the
> ixgbe/vhost/virtio_net/netmap interface in the VM show
Hi
I write a netmap program that sends packets to the network. my program
uses one netmap ring and fills the ring slots with packets.
My program needs to do something (action A) after a particular packet
(packet P) in the ring slot is sent to the network. so the program tracks
the position of the
loopback
device, about 1 million frames/sec, which is looping them all back, but
the macvtap interface on the host that feeds into the
ixgbe/vhost/virtio_net/netmap interface in the VM shows about 80-90% of
them as dropped. CPU usage is low in the VM, very roughly 25% for the
TX thread and 5% for the
gt; > So you are using netmap only in the guest (and not in the host).
> > And you are running a sender and a receiver inside the VM, both on the
> > VM interface.
> > Something like this
> >
> > # pkt-gen -i eth1 -f rx
> > # pkt-gen -i eth1 -f tx
>
> Y
Vincenzo Maffione wrote:
> So you are using netmap only in the guest (and not in the host).
> And you are running a sender and a receiver inside the VM, both on the
> VM interface.
> Something like this
>
> # pkt-gen -i eth1 -f rx
> # pkt-gen -i eth1 -f tx
Yes
So you are using netmap only in the guest (and not in the host).
And you are running a sender and a receiver inside the VM, both on the VM
interface.
Something like this
# pkt-gen -i eth1 -f rx
# pkt-gen -i eth1 -f tx
?
What happens if you use pkt-gen rather than your application?
2017-10-26 16
Vincenzo Maffione wrote:
> I guess you are using a FreeBSD guest. Is this the case? If you have the
Sorry, I am using LINUX, ubuntu 16.04 LTS for both host and VM. I am
posting here at standing request of netmap driver author.
The host has 24 CPUs @ 2.5 GHz and 128G of memory and is *idle* s
I guess you are using a FreeBSD guest. Is this the case? If you have the
chance, try a linux guest to check if virtio-net works better there (I've
used netmap on the netmap-patched virtio-net in Linux guests, never tried
on FreeBSD).
The netmap ring size is just the NIC ring size. If you c
I am running virtio_net (netmap-modified) on top of netmap (latest) in a
KVM virtual machine. The host adapter is Intel 82599ES 10G and the VM
is connected to it via macvtap.
My test setup is a small program in the VM sending frames out to an
external loopback device and watching what comes back
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
Ryan Stone changed:
What|Removed |Added
CC||rst...@freebsd.org
--- Comment #12 fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
--- Comment #11 from Cassiano Peixoto ---
Hi guys,
Any update about this issue?
Thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222744
Stephen Hurd changed:
What|Removed |Added
Assignee|freebsd-net@FreeBSD.org |sh...@freebsd.org
--
You are recei
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222744
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
--
You are
--- Comment #10 from Vincenzo Maffione ---
Hi,
For the moment being, unfortunately, netmap needs to do bring the interface
down in order to put the NIC in "netmap mode" (nm_register method in the code).
At the end of the registration, the interface is brought up again.
We bring the interface do
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
--- Comment #9 from Cassiano Peixoto ---
(In reply to Eric Joyner from comment #7)
Hi Eric,
It happens by chance, but i used to run a netmap application and many times it
stops working and i need to reboot the server. Just to make sure
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
--- Comment #8 from Eric Joyner ---
(In reply to Eric Joyner from comment #7)
and to add to this, I see this on ixgbe in 12-CURRENT, too. Though, with the
impending conversion to iflib, this may end up being overcome/have its nature
change
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
--- Comment #7 from Eric Joyner ---
(In reply to Cassiano Peixoto from comment #6)
I can reproduce it after many times, but I don't know what would be causing it.
I don't know much about the inner workings of netmap.
Can
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
--- Comment #6 from Cassiano Peixoto ---
(In reply to Eric Joyner from comment #5)
Hi Eric,
It's normal flaps when run pkt-gen. It always worked on this way.
Could you reproduce the issue?
I'm using 82599ES Intel NIC.
Thanks.
--
You a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
--- Comment #5 from Eric Joyner ---
And also, what card are you using?
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https:
s. It seems like a bizarre thing for
pkt-gen or netmap to do.
--
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any
||regression
Assignee|freebsd-b...@freebsd.org|e...@freebsd.org
Summary|Netmap issue after ixgbe|Netmap issue after ixgbe
|driver update |driver update in r320897
--
You are receiving this mail because:
You are on the CC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
--- Comment #3 from Cassiano Peixoto ---
(In reply to Cassiano Peixoto from comment #2)
Sorry my typo, i had this behavior only with 3.2.12-k driver.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
--- Comment #2 from Cassiano Peixoto ---
(In reply to Eric Joyner from comment #1)
Hi Eric,
You need to use two servers like this:
serverA ServerB
On serverA run:
pkt-gen -i ix0 -f rx -p4 -c4
On serverB run:
pkt-gen -i ix0 -f rx
R
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
--- Comment #1 from Eric Joyner ---
(In reply to Cassiano Peixoto from comment #0)
"When ixgbe interface is opened many times"
Could you clarify what that means? Does it mean just running pkt-gen
repeatedly, without manipulating the state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
Sean Bruno changed:
What|Removed |Added
Status|New |In Progress
Keywords|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221317
Cassiano Peixoto changed:
What|Removed |Added
CC||freebsd-net@FreeBSD.org,
gt; >
> > Actually, we would also need one beteween the following two options:
> > 1) Implementing a dummy if_start() for if_loop.c
> > 2) Prevent netmap from using if_loop.
>
> Hi,
>
> Please, check the attached patches.
>
> Luiz
>
> >
> > 2017-
On 12 July 2017 at 02:19, Vincenzo Maffione wrote:
> Yes.
>
> Actually, we would also need one beteween the following two options:
> 1) Implementing a dummy if_start() for if_loop.c
> 2) Prevent netmap from using if_loop.
Hi,
Please, check the attached patches.
Luiz
>
> 20
Yes.
Actually, we would also need one beteween the following two options:
1) Implementing a dummy if_start() for if_loop.c
2) Prevent netmap from using if_loop.
Cheers,
Vincenzo
2017-07-11 22:05 GMT+02:00 Marius Strobl :
> On Thu, Jul 06, 2017 at 02:19:42PM -0700, Vincenzo Maffione wr
03, 2017 at 05:08:09PM +0200, Vincenzo Maffione wrote:
> > > Details here:
> > >
> > > https://github.com/luigirizzo/netmap/issues/322
> > >
> > > Is it acceptable to commit the proposed patch?
> >
> > As suggested by hselasky@, the outliner pro
On 5 July 2017 at 08:05, Marius Strobl wrote:
> On Mon, Jul 03, 2017 at 05:08:09PM +0200, Vincenzo Maffione wrote:
>> Details here:
>>
>> https://github.com/luigirizzo/netmap/issues/322
>>
>> Is it acceptable to commit the proposed patch?
>
> As suggested by
Sure, can anyone commit this?
Il 5 lug 2017 4:05 AM, "Marius Strobl" ha scritto:
> On Mon, Jul 03, 2017 at 05:08:09PM +0200, Vincenzo Maffione wrote:
> > Details here:
> >
> > https://github.com/luigirizzo/netmap/issues/322
> >
> > Is it acceptable to
On Mon, Jul 03, 2017 at 05:08:09PM +0200, Vincenzo Maffione wrote:
> Details here:
>
> https://github.com/luigirizzo/netmap/issues/322
>
> Is it acceptable to commit the proposed patch?
As suggested by hselasky@, the outliner problem at hand is better solved
by a dummy if_start
Details here:
https://github.com/luigirizzo/netmap/issues/322
Is it acceptable to commit the proposed patch?
Thanks,
Vincenzo
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any
t open eth4 and eth5 if they
>> are bond, as the device are being used by the lagg pseudo-driver.
>> Since this driver does not have netmap support for the moment being,
>> there is no way you can get the native mode performance if you use lagg.
>>
>> If you just need
pseudo-driver.
> Since this driver does not have netmap support for the moment being, there
> is no way you can get the native mode performance if you use lagg.
>
> If you just need some failover in your application, you could just
> implement a simple failover mechanism in your applic
Hi,
It is an expected behaviour that you cannot open eth4 and eth5 if they
are bond, as the device are being used by the lagg pseudo-driver.
Since this driver does not have netmap support for the moment being, there
is no way you can get the native mode performance if you use lagg.
If you just
Hi all,
I have a bonded interface bond0 which enslaves eth4 and eth5. When trying
to open the devices eth4 or eth5 via netmap, I get a "device in use" error.
Opening the bond0 interface directly in netmap works, however it is in
emulated mode (as expected of a pseudointerface)
W
You can play with NIC interrupt coalescing settings to keep them under
control (I don't know how in FreeBSD, but in Linux you would do that with
e.g. "ethtool -C rx-usecs 100").
As written in the last line of netmap(4), you must disable all the
offloadings when playing with netmap
Bezüglich Harry Schmalzbauer's Nachricht vom 06.06.2017 11:59 (localtime):
…
> Having other offloadings enabled or disabled (regardless if it's on
> parent or vlan-clone) doesn't matter, …
I must correct myself! At least when it comes to host-stack traffic.
Keeping offloadings enabled on the va
Bezüglich Harry Schmalzbauer's Nachricht vom 05.06.2017 20:25 (localtime):
> Bezüglich Vincenzo Maffione's Nachricht vom 05.06.2017 16:06 (localtime):
>
…
> First quick test shows you're right and this tiny diff solves a decent
> share of my (ESXi-replacing) problems:
>
> --- src/sys/net/if_vlan.c
2017-06-05 20:25 GMT+02:00 Harry Schmalzbauer :
> Bezüglich Vincenzo Maffione's Nachricht vom 05.06.2017 16:06 (localtime):
> > Hi Harry,
> > I've done some investigation on this issue (just for fun) , and I
> think I
> > may have found the issue.
> >
&g
Bezüglich Vincenzo Maffione's Nachricht vom 05.06.2017 16:06 (localtime):
> Hi Harry,
> I've done some investigation on this issue (just for fun) , and I think I
> may have found the issue.
>
> When using vlan interfaces, netmap use the emulated adapter, as the &quo
Hi Harry,
I've done some investigation on this issue (just for fun) , and I think I
may have found the issue.
When using vlan interfaces, netmap use the emulated adapter, as the "vlan"
driver is not netmap-enabled (and it cannot be).
To intercept RX packets, netmap replace
Bezüglich Vincenzo Maffione's Nachricht vom 01.06.2017 00:39 (localtime):
> Hi Harry,
> OVS integration with netmap is very patchy and Linux only. Most
> importantly, it is not the right way to go, for a number of reasons.
> The real solution would be to integrate netmap int
Hi Harry,
OVS integration with netmap is very patchy and Linux only. Most
importantly, it is not the right way to go, for a number of reasons.
The real solution would be to integrate netmap into OVS would be to follow
the DPDK-OVS approach: this means implementing the switching logic
completely
Bezüglich Harry Schmalzbauer's Nachricht vom 25.05.2017 18:01 (localtime):
> Hello,
>
> I found lots of interesting papers about research and improvements
> regarding Open vSwitch and netmap (on FreeBSD, e.g.
> http://changeofelia.info.ucl.ac.be/pmwiki/uploads/SummerSchool/Pr
You can suppress the warning with something like this:
# cd /usr/src/tools/tools/netmap
# WARNS=2 make
Regards,
Navdeep
On Tue, May 30, 2017 at 10:54 AM, Harry Schmalzbauer wrote:
> Hello,
>
> after merging netmap code from head I can't compile pkt-gen from
> usr/src/tools/t
Hello,
after merging netmap code from head I can't compile pkt-gen from
usr/src/tools/tools/netmap:
cc -O2 -pipe -Werror -Wall -Wextra -march=ivybridge -g -std=gnu99
-fstack-protector-strong-Qunused-arguments -Qunused-arguments
-std=gnu99 -fstack-protector-strong-Qunused-argu
is less than 65792).
Hmm, then thn I guess a default like dev.netmap.priv_ring_size has
changed, because my em txd/rxd were default 4096, for both, native
stable/11-netmap and HEAD-netmap...
Reducing r/txd to 1024 solved the problem (hw.em.rxd in loader.conf).
>>
>> Adding lagg still resul
till results in a panci, but with your latest
> "return()"-patch, it's different:
>
> 0x8042aefb is in freebsd_generic_rx_handler
> (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/
> netmap/netmap_freebsd.c:276).
> 271 struct netmap_generic
> Impressive, it needed just a small addition to sys/conf/files to make
> the linker happy :-)
I perpared a diff to merge HEAD's netmap code to 11.1-prerelease for
further tests (preferred over replacing stable/11 code with upstream
clone, since there were some post-sync (r307394, 2016 O
with your latest
"return()"-patch, it's different:
0x8042aefb is in freebsd_generic_rx_handler
(/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_freebsd.c:276).
271 struct netmap_generic_adapter *gna =
272 (struct netmap
26.05.2017 10:41 (localtime):
> > Ok, so you should try to completely replace the code in your
> > /usr/src/sys with the code in the upstream netmap
> > repository https://github.com/luigirizzo/netmap (sys directory).
>
> Sorry beeing so complicated; But is there a real chanc
Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 10:41 (localtime):
> Ok, so you should try to completely replace the code in your
> /usr/src/sys with the code in the upstream netmap
> repository https://github.com/luigirizzo/netmap (sys directory).
Sorry beeing so complicated
Ok, so you should try to completely replace the code in your /usr/src/sys
with the code in the upstream netmap repository
https://github.com/luigirizzo/netmap (sys directory).
2017-05-26 10:38 GMT+02:00 Harry Schmalzbauer :
> Bezüglich Vincenzo Maffione's Nachricht vom 26.05.20
Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:31 (localtime):
> Is lagg0 the only interface attached to vale0?
> Is lagg0 aggregating a VLAN interface?
>
> You can try this trivial patch
>
> diff --git a/sys/dev/netmap/netmap_generic.c
> b/sys/dev/netma
Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:31 (localtime):
> Is lagg0 the only interface attached to vale0?
Yes.
> Is lagg0 aggregating a VLAN interface?
No.
> You can try this trivial patch
>
> diff --git a/sys/dev/netmap/netmap_generic.c
> b/sys/dev/
Is lagg0 the only interface attached to vale0?
Is lagg0 aggregating a VLAN interface?
You can try this trivial patch
diff --git a/sys/dev/netmap/netmap_generic.c
b/sys/dev/netmap/netmap_generic.c
index f148b228..46a3c2c6 100644
--- a/sys/dev/netmap/netmap_generic.c
+++ b/sys/dev/netmap
Bezüglich Vincenzo Maffione's Nachricht vom 26.05.2017 09:14 (localtime):
> Hi,
> Your stack trace report this:
>
> #7 0x8069dc50 at vlan_input+0x1f0
>
> which means VLANs are involved, in some way. Is that the correct trace?
The trace is from the pnaic after doing 'vale-ctl -a vale0:l
ocaltime):
> > No, the thing is that I misinterpreted your stack trace. The patch is ok
> > for a different bug. It seems that the problem are vlans more than lagg.
> > Which interface did you put in netmap mode, em or em.345?
>
> Good morning,
>
> it was if_lagg it
Bezüglich Vincenzo Maffione's Nachricht vom 25.05.2017 22:57 (localtime):
> No, the thing is that I misinterpreted your stack trace. The patch is ok
> for a different bug. It seems that the problem are vlans more than lagg.
> Which interface did you put in netmap mode, em or em.345?
No, the thing is that I misinterpreted your stack trace. The patch is ok
for a different bug. It seems that the problem are vlans more than lagg.
Which interface did you put in netmap mode, em or em.345?
Il 25 mag 2017 10:46 PM, "Harry Schmalzbauer" ha
scritto:
Bezüglich Harry Schm
a lot!
> Hi, unfortunately I can't confirm it to be fixed.
>
> The kgdb output is exactly the same:
>
> (kgdb) list *0x80426714
> 0x80426714 is in generic_rx_handler
> (/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_generic.c:628).
&g
80426714
0x80426714 is in generic_rx_handler
(/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_generic.c:628).
623 struct netmap_adapter *na = NA(ifp);
624 struct netmap_generic_adapter *gna = (struct
netmap_generic_adapter *)na;
625
should be able to workaround the bug by setting
> >
> > # sysctl dev.netmap.generic_rings=1
>
> I'll recompile with your patch, thanks a lot!
>
> > And yes, if_lagg(4) doesn't have native netmap support, like all the
> > meta-drivers (e.g. vlan, tunn
401 - 500 of 1259 matches
Mail list logo
