Re: Netmap Library not getting installed on custom kernel installation

On Wed, Dec 16, 2020 at 9:53 PM Vincenzo Maffione wrote: > > On a side note, the netmap tools (pkt-gen, bridge, lb, etc.) should really > be a port. Another TODO item. > > There is already one port for an old version of pkt-gen: https://svnweb.freebsd.org/ports/head/net/pkt-gen/ And here is a cu

Re: Netmap Library not getting installed on custom kernel installation

Hi, Got around this issue by manually copying necessary in /usr/obj Looks like libnetmap (src/lib/libnetmap) is not built and installed by default. Manually built them and copied the "libnetmap.h" and "libnetmap.so" (not just the header file) to appropriate directories in /usr/obj helps to get pa

Re: Netmap bridge not working with 10G Ethernet ports

Hi Vincenzo, On Tue, Nov 24, 2020 at 8:54 PM Vincenzo Maffione wrote: > > Yeah, it's weird because axgbe also uses iflib(4). If the driver exposes > NIC head/tail pointers (sysctl) it may be useful to check what happens > there. > It may be that the NIC is dropping these packets for some reason

Re: Netmap bridge not working with 10G Ethernet ports

Il giorno mar 24 nov 2020 alle ore 03:57 Rajesh Kumar ha scritto: > Hi Vincenzo, > > Thanks for pointing this. > > On Sat, Nov 21, 2020 at 10:40 PM Vincenzo Maffione > wrote: > >> # ifconfig ix0 promisc >> # ifconfig ix1 promisc >> >> This is an additional requirement when using netmap bridge, b

Re: Netmap bridge not working with 10G Ethernet ports

Hi Vincenzo, Thanks for pointing this. On Sat, Nov 21, 2020 at 10:40 PM Vincenzo Maffione wrote: > # ifconfig ix0 promisc > # ifconfig ix1 promisc > > This is an additional requirement when using netmap bridge, because that > is not done automatically (differently from what happens with if_brid

Re: Netmap bridge not working with 10G Ethernet ports

Hi Rajesh, I think the issue here is simply that you have not enabled promiscuous mode on your interfaces. # ifconfig ix0 promisc # ifconfig ix1 promisc This is an additional requirement when using netmap bridge, because that is not done automatically (differently from what happens with if_bridg

Re: Netmap bridge not working with 10G Ethernet ports

Il giorno ven 20 nov 2020 alle ore 14:31 Rajesh Kumar ha scritto: > Hi Vincenzo, > > On Fri, Nov 20, 2020 at 3:20 AM Vincenzo Maffione > wrote: > >> >> Ok, now it makes sense. Thanks for clarifying. I see that if_axp(4) uses >> iflib(4). This means that actually if_axp(4) has native netmap suppo

Re: Netmap bridge not working with 10G Ethernet ports

Hi Vincenzo, On Fri, Nov 20, 2020 at 3:20 AM Vincenzo Maffione wrote: > > Ok, now it makes sense. Thanks for clarifying. I see that if_axp(4) uses > iflib(4). This means that actually if_axp(4) has native netmap support, > because iflib(4) has native netmap support. > > It means that the driver

Re: Netmap bridge not working with 10G Ethernet ports

Il giorno gio 19 nov 2020 alle ore 12:28 Rajesh Kumar ha scritto: > Hi Vincenzo, > > Thanks for your reply. > > On Thu, Nov 19, 2020 at 3:16 AM Vincenzo Maffione > wrote: > >> >> This looks like if_axe(4) driver, and therefore there's no native netmap >> support, which means you are falling back

Re: Netmap bridge not working with 10G Ethernet ports

Hi Vincenzo, Thanks for your reply. On Thu, Nov 19, 2020 at 3:16 AM Vincenzo Maffione wrote: > > This looks like if_axe(4) driver, and therefore there's no native netmap > support, which means you are falling back on > the emulated netmap adapter. Are these USB dongles? If so, how can they be >

Re: Netmap bridge not working with 10G Ethernet ports

Hi, Il giorno mer 18 nov 2020 alle ore 08:13 Rajesh Kumar ha scritto: > Hi, > > I am testing a 10G Network driver with Netmap "bridge" utility, where it > doesn't seem to work. Here is my setup details. > > *System under Test:* Running FreeBSD CURRENT. Has two inbuilt 10G NIC > ports. > *Syste

Re: Netmap - Vale switch - tcp problem

Il giorno sab 6 giu 2020 alle ore 20:32 Anthony Arnaud < antho.arnaudi...@gmail.com> ha scritto: > This works!! > A good news! > It works even if I connect the nic to vale switch directly from ssh, the > connection does not drop like before your patch. > Yes, connecting the vtnet0 to the vale swi

Re: Netmap - Vale switch - tcp problem

This works!! A good news! It works even if I connect the nic to vale switch directly from ssh, the connection does not drop like before your patch. Can you list the steps to setup the bridge in your tests? I thing "ifconfig bridge create" etc. Now I have to understand why it doesn't work in my prev

Re: Netmap - Vale switch - tcp problem

Il giorno ven 5 giu 2020 alle ore 18:16 Anthony Arnaud < antho.arnaudi...@gmail.com> ha scritto: > Hi Vincenzo, > Thank you for your answers. > I upgraded a guest machine in proxmox env to FreeBSD 13.0-CURRENT #0 > r361830. > After that I compiled the tools as usual from /src/tools/tools/netmap >

Re: Netmap - Vale switch - tcp problem

Hi Vincenzo, Thank you for your answers. I upgraded a guest machine in proxmox env to FreeBSD 13.0-CURRENT #0 r361830. After that I compiled the tools as usual from /src/tools/tools/netmap I configured 2 NIC vtnet vtnet0 with an ip 192.168.1.x vtnet1 without ip and csum disabled as mirror of vtnet

Re: Netmap - Vale switch - tcp problem

Hi Anthony, I fixed more bugs in the vtnet driver (in FreeBSD-CURRENT). As of r361760, I'm now able to run the following steps in a VM with a vtnet device # ifconfig vtnet0 -txcsum -rxcsum -tso4 192.168.100.2/24 # vale-ctl -h vale:vtnet0 # netperf -H 192.168.100.1 # Run a netperf TCP_STREAM tes

Re: Netmap - Vale switch - tcp problem

Hi Anthony, I think there is more than a bug, drivers-related, that show up when you attach the interface to a vale switch. I've found and fixed some related to if_vtnet (see below). In any case, in my tests there is no difference between TCP traffic and other (UDP, ICMP, STP,...). The issues are

Re: Netmap - Vale switch - tcp problem

Hi Vincenzo, To simplify the scenario I have installed from scratch FBSD12.1 on a new machine, without any virtualization env. I have encountered the same problem, when i attach an ethernet interface to vale switch (in this case an intel card em5) the tcp traffic disappears and tcpdump shown only

Re: Netmap - Vale switch - tcp problem

Il giorno ven 29 mag 2020 alle ore 19:01 Anthony Arnaud < antho.arnaudi...@gmail.com> ha scritto: > Hi Vincenzo, > > thanks for your hints! > I rebooted my guest FBSD 12.1 machine, and I have perfomed your steps > > #ifconfig vtnet1 -txcsum -rxcsum -tso4 -tso6 up promisc > > vtnet1: > flags=28943

Re: Netmap - Vale switch - tcp problem

Hi Vincenzo, thanks for your hints! I rebooted my guest FBSD 12.1 machine, and I have perfomed your steps #ifconfig vtnet1 -txcsum -rxcsum -tso4 -tso6 up promisc vtnet1: flags=28943 metric 0 mtu 1500 options=6c04b8 ether 0e:bd:ec:7a:08:06 media: Ethernet 10Gbase-T statu

Re: Netmap - Vale switch - tcp problem

Hi, I was trying to reproduce your problem (same FreeBSD release as yours). It looks like there is some sort of bad interaction with LRO. Starting from a fresh boot, if you keep lro enabled, e.g. # ifconfig vtnet0 -txcsum -rxcsum -tso4 -tso6 # vale-ctl then I experience no problem (TCP

Re: Netmap - Vale switch - tcp problem

I already disabled the checksum, the vtnet config is: ifconfig vtnet1 -txcsum -rxcsum -tso4 -tso6 -lro -txcsum6 -rxcsum6 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso -vlanhwcsum up promisc vtnet1: flags=28943 metric 0 mtu 1500 options=1800a8 ether 0e:bd:ec:7a:08:06 media:

Re: Netmap - Vale switch - tcp problem

On Thursday, May 28, 2020, Anthony Arnaud wrote: > Hi everyone! > I would like to create a vale switch with an interface attached with the > host stack and some virtual. > My env is a VM with FBSD-12.1 12.1-RELEASE FreeBSD 12.1-RELEASE r354233 > GENERIC amd64 > and VirtIO support. > > I performe

Re: netmap/ixl and crc addition..

Il giorno gio 26 mar 2020 alle ore 11:39 Alexandre Snarskii < s...@snar.spb.ru> ha scritto: > On Wed, Mar 25, 2020 at 11:31:30PM +0100, Vincenzo Maffione wrote: > > Hi Alexandre, > > Thanks. Your patch looks good to me. I assume you have tested it? > > Sure, this patch is already handles product

Re: netmap/ixl and crc addition..

On Wed, Mar 25, 2020 at 11:31:30PM +0100, Vincenzo Maffione wrote: > Hi Alexandre, >   Thanks. Your patch looks good to me. I assume you have tested it? Sure, this patch is already handles production traffic. > I will commit that to stable/11. Thanks. > > The issue you report on stable/12 is m

Re: netmap/ixl and crc addition..

On Wed, Mar 25, 2020 at 11:31:30PM +0100, Vincenzo Maffione wrote: > Hi Alexandre, > Thanks. Your patch looks good to me. I assume you have tested it? > I will commit that to stable/11. > > The issue you report on stable/12 is more worrisome. The 'no space in TX > ring' condition (head==cur==ta

Re: netmap/ixl and crc addition..

Hi Alexandre, Thanks. Your patch looks good to me. I assume you have tested it? I will commit that to stable/11. The issue you report on stable/12 is more worrisome. The 'no space in TX ring' condition (head==cur==tail) is ok per-se: on a subsequent poll() wakeup (e.g. TX interrupt) or explicit

Re: netmap/ixl and crc addition..

On Tue, Mar 24, 2020 at 03:37:36PM +0300, Alexandre Snarskii wrote: > > Hi! > > Long story short: looks like intel x722 does not by default add CRC to > outbound frames, so with FreeBSD 11-stable netmap-generated traffic is > dropped on the next port.. Fix is simple, attached. ... add missing

Re: netmap on cxgb (Chelsio T3) — panic on transmit

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

Re: netmap & chelsio

Hi, On 2018-7-11, at 18:53, Navdeep Parhar wrote: > Try changing lazy_tx_credit_flush to 0 on the running kernel with a > debugger, or compile the driver with it set to 0 -- it's in t4_netmap.c: > > int lazy_tx_credit_flush = 1; thanks! With that, I get performance similar to the ixl cards on f

Re: netmap & chelsio

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

Re: netmap & chelsio

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? In case it matters, here is what is in loader.conf: hw.cxgbe.num_vis=2 hw.cxgbe.fl_pktshift=0 hw.cxgbe.ntxq=1 hw.cxgbe.

Re: netmap & chelsio

On Fri, Jul 06, 2018 at 06:41:53AM +, Eggert, Lars wrote: > Hi, > > On 2018-7-5, at 17:47, n...@freebsd.org wrote: > > Set hw.cxgbe.fl_pktshift=0 in loader.conf to stop the chip from doing > > this. See cxgbe(4) for details on the knob. It's a historic > > optimization that doesn't seem to m

Re: netmap & chelsio

Hi, On 2018-7-5, at 17:47, n...@freebsd.org wrote: > Set hw.cxgbe.fl_pktshift=0 in loader.conf to stop the chip from doing > this. See cxgbe(4) for details on the knob. It's a historic > optimization that doesn't seem to matter on modern CPUs, so the driver > default should probably be 0 instead

Re: netmap & chelsio

On Thu, Jul 05, 2018 at 03:09:33PM +, Eggert, Lars wrote: > Hi, > > when receiving packets via netmap (current GitHub version) on a Chelsio T6 > vcc0 device on -CURRENT, it appears that the Ethernet header starts at an > offset of two bytes into the netmap slot. So far, I have only used netmap

Re: netmap: How the buf_num of buffers is used by driver and monitor app

Hi, 2018-03-30 6:00 GMT+02:00 Ming Fu : > Hi, > > I am wondering about the netmap module parameters buf_num. The default > buf_num 163840 seems fairly big compare to intel 10G ixgbe of max 4096 > queue size. A full queue of the interface can only use a very small portion > of the buf_num. Can th

Re: Netmap on Linux nm_open() fail when receive ring size is set to 4096

Hi, You need to increase the value of some netmap module parameter. At least ring_size, maybe also buf_num. Then restart your netmap applications. Keep in mind that performance could worsen with more slots, because of increased cache thrashing. Cheers, Vincenzo On Wed, Mar 28, 2018, 3:50 PM

Re: netmap ixgbevf mtu

Grazie mille. I will test it as time allows -- swamped. Joe Buehler Vincenzo Maffione wrote: > Hi, > This commit (fe13476b106ed1f4b517b1590e1dfb3f268b6e78) in the upstream > netmap should have fixed the NS_MOREFRAG issue for ixgbe. > If you happen give a try let us know. > > Cheers, > Vincen

Re: netmap ixgbevf mtu

Hi, This commit (fe13476b106ed1f4b517b1590e1dfb3f268b6e78) in the upstream netmap should have fixed the NS_MOREFRAG issue for ixgbe. If you happen give a try let us know. Cheers, Vincenzo 2018-03-21 21:40 GMT+01:00 Vincenzo Maffione : > I see. Unfortunately this breaks the API, so I don't th

Re: netmap ixgbevf max frame size

Joseph H. Buehler wrote this message on Wed, Mar 21, 2018 at 09:32 -0400: > This turned out to be a limitation of the box we are using, there is > apparently hardware between the ixgbevf chip and the fiber. I've written a program that will probe the sizes that work successfully, set the route's M

Re: netmap ixgbevf mtu

I see. Unfortunately this breaks the API, so I don't think we can accept it. We should probably sum up the fragment lengths, remember which one was the first descriptor and write the olinfo field when we process the last descriptor ... I hope this does not slow down the simpler case where NS_MOREFR

Re: netmap ixgbevf max frame size

This turned out to be a limitation of the box we are using, there is apparently hardware between the ixgbevf chip and the fiber. Joe Buehler > I am unable to send frames larger than 9216 bytes (destination MAC through > trailing CRC inclusive) using ixgbevf hardware with latest netmap code > (

Re: netmap ixgbevf mtu

Attached is a patch that allows fragmented TX with the ixgbevf driver. For the first TX buffer set the slot length to the full length of the frame and make sure that the slot buffer is fully filled. For succeeding slots just set the length to the amount of the buffer filled. Not intended as th

Re: netmap ixgbevf mtu

If you could fix this I would appreciate it. My L1 TX performance for 64 byte L2 frames drops significantly, from about 9 gigbits to 7 gigabits, when I use buffers large enough to hold jumbo frames. I will play with it a bit locally. One thing that occurs to me is to pass the full frame lengt

Re: netmap ixgbevf mtu

2018-03-19 20:49 GMT+01:00 Joe Buehler : > Vincenzo Maffione wrote: > > > To receive a frame larger than the RX buffer size you need multiple > > netmap slots (as multiple descriptors are > > used by the hardware), looking at the NS_MOREFRAG flag. > > See the example code in utils/functional.c::rx

Re: netmap ixgbevf mtu

Vincenzo Maffione wrote: > To receive a frame larger than the RX buffer size you need multiple > netmap slots (as multiple descriptors are > used by the hardware), looking at the NS_MOREFRAG flag. > See the example code in utils/functional.c::rx_one(). This works fine -- thanks. > Also TX may ha

Re: netmap ixgbevf mtu

First, please make sure to use the latest netmap from github. Yes, drivers in general use 2K or 4K RX buffers regardless of the MTU or netmap buffer size. To receive a frame larger than the RX buffer size you need multiple netmap slots (as multiple descriptors are used by the hardware), looking at

Re: netmap ixgbevf mtu

Sorry, I should have added, this is LINUX if it matters. Joe Buehler wrote: > I am having difficulties with netmap over top of ixgbevf when attempting to > use a large MTU (say 9000 bytes). > > Does the ixgbevf driver use 2048 byte buffers for RX regardless of the MTU or > netmap buffer size? >

Re: netmap memory config query

Hi, The parameter to increase is "ring_size". FreeBSD or Linux does not matter (except for how you modify the parameter, i.e. sysctl on FreeBSD and sysfs in Linux). Cheers, Vincenzo 2018-03-14 20:59 GMT+01:00 Joe Buehler : > When I increase the ixgbevf rx ring size from 1024 to 4096 I get th

Re: Netmap: Build a network SPAN/TAP from netmap

Yes, or if you prefer you can simply extend "bridge" forwarding logic to copy every packet to an additional TAP port. Copying a packet in netmap is just a matter of initialize the next struct netmap_slot in the destination (TAP) netmap ring, memcpy() the packet payload and incrementing ring->cur/ri

Re: Netmap: Build a network SPAN/TAP from netmap

> On Dec 14, 2017, at 12:00 PM, Ming Fu wrote: > > Hi, > > I am trying to explore the possibility to build a network SPAN/TAP from > netmap. Similar to the bridge sample, but all packet going through the bridge > also get copied to a SPAN port. How do I duplicate or clone an incoming > pack

Re: Netmap ouch double free

Hi Vincenzo, Thank you for pointing me in right direction. Yes indeed, those were overflow buffers that did the trick. I did not point them back before closing. (I am using linux). Martina On Dec 3, 2017 08:56, "Vincenzo Maffione" wrote: > Hi, > It may be related to the "extra buffers feat

Re: Netmap ouch double free

Hi, It may be related to the "extra buffers feature" of netmap, that lb uses. When the netmap port is opened, some additional buffers (not bound to any netmap ring) are allocated to be used by the application for slot swapping. They are provided through the ni_bufs_head field as a linked list (se

Re: netmap / LINUX realtime / ixgbevf: huge RX latencies

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: > > > HEAD or 11? > >

Re: netmap / LINUX realtime / ixgbevf: huge RX latencies

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 trivial p

Re: netmap / LINUX realtime / ixgbevf: huge RX latencies

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 source > does not

Re: netmap / LINUX realtime / ixgbevf: huge RX latencies

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

Re: netmap/vale periodic deadlock

Hi, $ bridge -h for usage. Yes, bridge is just a simple example program, and stays in foreground. Probably using daemon(8) you can turn it into a daemon. Cheers, Vincenzo 2017-11-22 10:18 GMT+01:00 Harry Schmalzbauer : > Bezüglich Harry Schmalzbauer's Nachricht vom 22.11.2017 09:39 (localt

Re: netmap/vale periodic deadlock

Bezüglich Harry Schmalzbauer's Nachricht vom 22.11.2017 09:39 (localtime): > Bezüglich Vincenzo Maffione's Nachricht vom 22.11.2017 09:04 (localtime): >> >> 2017-11-21 21:48 GMT+01:00 Harry Schmalzbauer > >: >> >> Bezüglich Vincenzo Maffione's Nachricht vom 21.11.201

Re: netmap/vale periodic deadlock

Bezüglich Vincenzo Maffione's Nachricht vom 22.11.2017 09:04 (localtime): > > > 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, althou

Re: netmap/vale periodic deadlock

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. > > Since VLAN interfaces like vlan0 do not have

Re: netmap/vale periodic deadlock

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 > netmap support, you are falling b

Re: netmap/vale periodic deadlock

Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 14:26 (localtime): > 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 si

Re: netmap/vale periodic deadlock

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 some

Re: netmap/vale periodic deadlock

Bezüglich Vincenzo Maffione's Nachricht vom 21.11.2017 09:39 (localtime): > Hi, > It's hard to say, specially because it happens after two days of > normal use. > Can't you enable deadlock debugging features in your kernel? > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/k

Re: netmap/vale periodic deadlock

Hi, It's hard to say, specially because it happens after two days of normal use. Can't you enable deadlock debugging features in your kernel? https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html However, if I understand correctly you have created some

Re: [netmap] when does a packet in the netmap ring send out exactly

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

Re: [netmap] when does a packet in the netmap ring send out exactly

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 , it behaves as wha

Re: [netmap] when does a packet in the netmap ring send out exactly

Hi, I think if you call the TXSYNC ioctl without advancing the head pointer, then the tail is advanced as much as possible. Cheers luigi On Mon, Nov 20, 2017 at 3:35 PM, Xiaoye Sun wrote: > Hi, > > I found that the tail pointer only moves when the ring has less than half > of the slots available

Re: [netmap] when does a packet in the netmap ring send out exactly

Hi, I found that the tail pointer only moves when the ring has less than half of the slots available. This prevents me from knowing the accurate time when the packet in a slot is processed. Is there a way to move the tail pointer as long as the packet in the slot is processed? Is this a configurab

Re: netmap scatter/gather?

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 don't want to add the missing s

Re: netmap scatter/gather?

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 > change the netmap buff

Re: netmap scatter/gather?

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 > -- Vincenzo Maffione

Re: netmap scatter/gather?

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"

Re: netmap scatter/gather?

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 tuning the sysctl > dev.net

Re: netmap scatter/gather?

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 increase it to

Re: [netmap] when does a packet in the netmap ring send out exactly

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 explicit indication o

Re: Netmap with bonded interfaces

Bypass what? 2017-06-28 22:59 GMT-07:00 Paras Jha : > It's possible to bypass this by unloading and reloading the patched > network driver > > On Thu, Jun 29, 2017 at 12:39 AM, Vincenzo Maffione > wrote: > >> Hi, >> It is an expected behaviour that you cannot open eth4 and eth5 if they >> are

Re: Netmap with bonded interfaces

It's possible to bypass this by unloading and reloading the patched network driver On Thu, Jun 29, 2017 at 12:39 AM, Vincenzo Maffione wrote: > 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. > Sin

Re: Netmap with bonded interfaces

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 n

Re: Netmap zero-copy with multiple NICs

Hi, Yes, by default netmap packet buffers for all physical nics on your machine are allocated from the same memory area. This means that you can do zcopy with the usual swap of netmap slots. The bridge application is an example. It does zcopy if possible, otherwise it falls back to copying. Che

Re: Netmap pipe zero-copy with NIC buffer?

Thank you for the clarification! On Wed, Apr 12, 2017 at 3:50 AM, Vincenzo Maffione wrote: > netmap applications always bypass the kernel (network stack). There is > only a distinction between ports opened in "native" mode and "emulated" > mode. > If NIC driver doesn't have native netmap support

Re: Netmap pipe zero-copy with NIC buffer?

netmap applications always bypass the kernel (network stack). There is only a distinction between ports opened in "native" mode and "emulated" mode. If NIC driver doesn't have native netmap support, the legacy driver is internally used by netmap to transmit and receive (and this is called "emulated

Re: Netmap pipe zero-copy with NIC buffer?

Apologies, by KB I meant kernel bypass, since it is possible to open a netmap port without bypassing the kernel. I didn't know if this would affect it or not. On Sun, Apr 9, 2017 at 3:20 AM, Vincenzo Maffione wrote: > Hi, > Yes, when you nm_open("netmap:em3{2", ...), you're opening a netmap pi

Re: Netmap pipe zero-copy with NIC buffer?

Hi, Yes, when you nm_open("netmap:em3{2", ...), you're opening a netmap pipe in the same netmap memory area as the one used by nm_open("netmap:em3", ...). As a result, you can zero-copy packets from NIC rings to pipe rings. What do you mean by "KB mode"? Cheers, Vincenzo 2017-04-08 19:56 GMT

Re: netmap error on -CURRENT with em and igb

On 02/16/17 02:25, Giuseppe Lettieri wrote: > Hi all, > > the "Operation not permitted" is coming from iflib_netmap_register: > > ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); > ... > IFDI_INIT(ctx);// for igb it calls em_if_init() > ... > return (ifp->if_dr

Re: netmap error on -CURRENT with em and igb

Hi all, the "Operation not permitted" is coming from iflib_netmap_register: ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); ... IFDI_INIT(ctx); // for igb it calls em_if_init() ... return (ifp->if_drv_flags & IFF_DRV_RUNNING ? 0 : 1); the last

Re: Netmap TX with no impact to host

You're welcome! I know it's a bit difficult to notice, but this is written in the very last sentence of the netmap(4) man page. Cheers, Vincenzo 2017-01-19 13:50 GMT+01:00 David Belle-Isle : > Oh! Thank you s much! I was missing the last part about the checksum > offloadings and TSO. I dis

Re: Netmap TX with no impact to host

Oh! Thank you s much! I was missing the last part about the checksum offloadings and TSO. I disabled them and everything is working perfectly now! Thank you so much!! On Thu, Jan 19, 2017 at 6:00 AM, Vincenzo Maffione wrote: > Hi, > Before answering to the question, some important disclaim

Re: Netmap TX with no impact to host

Hi, Before answering to the question, some important disclaimers. If you are using FreeBSD-12-current, please be aware that there are IFLIB developments in progress that affect em devices. Unfortunately, at the moment netmap does not work on em/lem/igb devices because of the switch to IFLIB at t

Re: netmap, netmap-fwd, and how many M packets-per-second?

Hi, If I'm getting it right, you are doing a test with 10 machines directly connected on the same LAN, using iperf to test the performance of the TCP/IP stack with your 10Gbit cards. But as far as I can see, netmap is not involved in your setup, you are not using it, aren't you? IOW , I don't und

Re: netmap, netmap-fwd, and how many M packets-per-second?

Hi, I have run some performance tests but not as router, which is your case, so some information might not be relevant: 0. validate your hw stats with what you get from the output 1. Try using FLOWTABLE option in your kernel config - this may kill your machine in -CURRENT, but it's worth checking

Re: netmap, netmap-fwd, and how many M packets-per-second?

How have you configured netmap-fwd? If you provide details on how the router or firewall is setup I can try similar experiments here. On Thu, Dec 1, 2016 at 3:55 PM, Jordan Caraballo wrote: > Feedback and/or tips and tricks more than welcome. > > We are trying to process huge amounts of small (6

Re: netmap, netmap-fwd, and how many M packets-per-second?

(I'm not subscribed to -hpc or -performance, so I've trimmed the recipients.) You're running iperf3 on an Ivy Bridge Xeon at 2.4GHz. -N (--no-delay) only applies to TCP, it disables Nagle's algorithm, so it doesn't apply for "-u" (--udp). In any case, iperf3 still attempts to use large enough fr

Re: NETMAP application architecture question

On Fri, Sep 16, 2016 at 05:05:33PM +0200, Luigi Rizzo wrote: > Hi, > I don't think there is any hard limitation on the total number > of pipes, very likely the number (64) is just some arbitrary > limit that we set, and can be increased through a sysctl or > worst case a compile time constant. >

Re: NETMAP application architecture question

I am "VERY WILLING" to test out a specific branch of FreeBSD current with this code merged. There are wonderful features such as the new LB app in the new code that I would greatly desire to be included in FreeBSD. I tried to do a simple merge and it was more involved. I was hoping to have some ti

Re: NETMAP application architecture question

On Fri, Sep 16, 2016 at 5:14 PM, Slawa Olhovchenkov wrote: > On Fri, Sep 16, 2016 at 05:05:33PM +0200, Luigi Rizzo wrote: > > >> Please have a look at the source code if you can find where >> you are hitting the limit, and which parameters are involved. >> In case you don't find it, get back to u

Re: NETMAP application architecture question

On Fri, Sep 16, 2016 at 05:05:33PM +0200, Luigi Rizzo wrote: > Hi, > I don't think there is any hard limitation on the total number > of pipes, very likely the number (64) is just some arbitrary > limit that we set, and can be increased through a sysctl or > worst case a compile time constant. I

Re: NETMAP application architecture question

Hi, I don't think there is any hard limitation on the total number of pipes, very likely the number (64) is just some arbitrary limit that we set, and can be increased through a sysctl or worst case a compile time constant. Please have a look at the source code if you can find where you are hittin

Re: Netmap Checksum Offloading

> On 16 Jun 2016, at 08:40, Dominik Schoeffmann wrote: > > Is the checksum offloading patch for the igb(4) driver available online? > (I could not find it) > I would really like to take a look at it, espacially the context > descriptor part of it. I would also be interested in it... For looking a

  1   2   3   4   >