From nobody Mon Sep 26 16:05:03 2022 X-Original-To: net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4Mbnf423RGz4XQkm for ; Mon, 26 Sep 2022 16:05:16 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Mbnf41X1Qz46MK for ; Mon, 26 Sep 2022 16:05:16 +0000 (UTC) (envelope-from vmaffione@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664208316; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=S9M1RuA8OwLa8Qejv+EKZUJwdlMFmkvrJf9pb2PRIrI=; b=rNSZuj9bUZymwTHz1J950cIfNevKodCwrgz7JQz6epKJjWJqmXOzOC/NBW8Rvs8Ejvf2zD 1rqQqQ6NFjy1trRW3sBpy3s22C0Sp8LPHOeGvr/0Wzc4sKn7GOuGZZwbB6F9vvssanCj+E /8oGVVht4CPwTMFMwlMQuynnB/omivj+Ze/sJIhvtTo8TBMs2/pyDbtyafaz4c9TLczfC0 Dw/f18LjMeN/4RmBALCnadKs8MHyQglZd154kjAAF4g84b/5jmW+ANcPWJ/etX4rZc/S7w u4hhFVJCKkYupKYcvtZThT3WU7lY6O6Yhsovr3ppnW62skDqNE/yf7Iz+A9qRA== Received: from mail-pg1-f181.google.com (mail-pg1-f181.google.com [209.85.215.181]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: vmaffione) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Mbnf40W2JzhRg for ; Mon, 26 Sep 2022 16:05:16 +0000 (UTC) (envelope-from vmaffione@freebsd.org) Received: by mail-pg1-f181.google.com with SMTP id 129so5534261pgc.5 for ; Mon, 26 Sep 2022 09:05:16 -0700 (PDT) X-Gm-Message-State: ACrzQf2wRD8PSTmWJM2uejsWnDpttvkp0nZOEmRdP5UKYbloj4BvTvPb bj6bNpCe9RlzhGk19yM0aNhZacaws1X0EUZ9emI= X-Google-Smtp-Source: AMsMyM6uFWebtFqe1XM18dWyrId0haDWuyDvGW7gqJoQGeKUmYi8As0iA3MZOMu7yI/LuuYMvf7jtNCqIQ9XTvXOJEY= X-Received: by 2002:a65:57c2:0:b0:438:ac40:1460 with SMTP id q2-20020a6557c2000000b00438ac401460mr20856637pgr.216.1664208314814; Mon, 26 Sep 2022 09:05:14 -0700 (PDT) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Vincenzo Maffione Date: Mon, 26 Sep 2022 18:05:03 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Forwarding packets to the host stack in net map lb app To: Kim Shrier Cc: "net@freebsd.org" , Giuseppe Lettieri Content-Type: multipart/alternative; boundary="0000000000006fd98c05e996b15d" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1664208316; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=S9M1RuA8OwLa8Qejv+EKZUJwdlMFmkvrJf9pb2PRIrI=; b=lMKRhVdV464xtdxhKahQdPxVzojMTDJVN6FI/Qkz4981g4WdVo8jXXV7YNvQM0x9CSXoY6 jtWZYD1EAtEPpRxOYi87bUXeSWqSUlixbrnLfGKemwpRWIkJu2NLyCZpkeG9L2+SthkZV5 isgFrqLaVD/HSjguDwgRclcKeFfy/DCEJAp3+XdZkPZhvjOr8Urcl/Cl+h99ZR/Qy+Akj6 rxhpym7eX5rww2GF/mrfWTyjcYQwb6mu7kaGL1ow/pXL0myrUocfnhqwrqF6QJcMyfpw4j S2nImQKWCP8VclAivlt2Sb5PwLLtgfCiMrT4D5H9AhV0orgBdAMx69YYD4XqjA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1664208316; a=rsa-sha256; cv=none; b=SgJHJQ/VG6myZsvCSYSZDPP3F4iF+Xtmg584PuatU+yP5Q3IvWldxFNK/Qgy9XaaEVN5Pt qSN8PX29Bkm97EJwN3G6Rv+fMW7pYh9qGgeMXBkcgqa3jLHnOTY4roKGR+neOyJdILma2k 19cmwC+v+yCdbYYP0uRmbOUr2ub+GRvu5ktaZLD3/oPy0ZKjYJ5SFO8ARGG5BneTNh1r5o smDhGUwyPfGXayoSmUSi7ckULqQ6fpAxpUYyAZ4Ky6DOpeIgdEQEJ4Gl6BDXgNZgMOPWJp RKUFRTM68cVDblc3Ub36vQawzk6Ouq95MBQ6aOskU+v41bcu0FsiE5kLJhw8+Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --0000000000006fd98c05e996b15d Content-Type: text/plain; charset="UTF-8" I think you could avoid any modifications to lb(8) and take advantage of the "multiple pipe groups" feature. You open two groups, # lb -i netmap:em0/R -p mon:$N -p fwd:$M [...] Each group receives all the packets arriving on the RX (NIC) rings of em0. (I'm pretty sure) this happens without packet copies, i.e. by swapping netmap slots. The first group (mon) is for your existing monitor process. The second one (fwd) would be used for a separate process that handles the host stack: - It reads from fwd:$M pipes, selecting only the RX packets that should be forwarded to the host stack. Selected packets will be forwarded to netmap:em0^/T. All the other packets are just dropped. - it forwards all traffic from netmap:em0^/R to netmap:em0/T (e.g. from the em0 host RX ring to the em0 TX rings). Keep in mind that lb does not touch em0 TX rings, so there would not be conflicts. In any case, it is good practice to have lb only open RX rings (netmap:em0/R). This second process can probably be a modified version of the netmap bridge, although you have asymmetric three-party forwarding here (fwd/R --> netmap:em0^T, netmap:em0^/R --> netmap:em0/T). The alternative (harder) option would be to actually modify lb(8). You should probably: - open netmap:em0^/R and netmap:em0*/T with separate nmport_open() calls - parse the packet before pkt_hdr_hash() to select the RX packets that you need to forward to the host TX ring, and modify the forwarding logic to perform this task. - modify the logic of the lb poll() loop so that it also performs the forwarding from host RX rings to NIC TX rings I'm not sure that you would have any advantages by choosing this path. Cheers, Vincenzo Il giorno dom 18 set 2022 alle ore 23:47 Kim Shrier ha scritto: > I have a network monitoring program and I am using the lb app from > netmap to distribute packets to netmap pipes. The monitor processes > are successfully receiving packets. > > I would like to modify lb to send some packets to the host stack and > have packets coming from the host stack go out on the monitoring > ethernet interface. > > I am relatively new to using netmap and it is not obvious to me how > to properly send/receive some packets to the host tx/rx rings while > still letting the the netmap pipes forward packets to my monitoring > application. > > I have looked at the bridge app from netmap which opens 2 netmap > ports. It does not seem to me that that would be the right way to > deal with the host stack in the context of lb. > > Should I just process the last tx/rx ring differently from the first ones > that are forwarding packets to the netmap pipes? > > Thanks, > Kim > > > > --0000000000006fd98c05e996b15d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think you could avoid any modifications to lb(8) an= d take advantage of the "multiple pipe groups" feature.
You open two groups,
# lb -i netmap:em0/R -p mon:$N -p fwd:= $M [...]
Each group receives all the packets arriving on the RX (= NIC) rings of em0. (I'm pretty sure) this happens without packet copies= , i.e. by swapping netmap slots.

The first gro= up (mon) is for your existing monitor process. The second one (fwd) would b= e used for a separate process that handles the host stack:
=C2=A0= - It reads from fwd:$M pipes, selecting only the RX packets that should be = forwarded to the host stack. Selected packets will be forwarded to netmap:e= m0^/T. All the other packets are just dropped.
=C2=A0- it for= wards all traffic from netmap:em0^/R to netmap:em0/T (e.g. from the em0 hos= t RX ring to the em0 TX rings). Keep in mind that lb does not touch em0 TX = rings, so there would not be conflicts. In any case, it is good practice to= have lb only open RX rings (netmap:em0/R).
This second process c= an probably be a modified version of the netmap bridge, although you have a= symmetric three-party forwarding here (fwd/R --> netmap:em0^T, netmap:em= 0^/R --> netmap:em0/T).

The alternative (harder= ) option would be to actually modify lb(8). You should probably:
= =C2=A0- open netmap:em0^/R and netmap:em0*/T with separate nmport_open() ca= lls
=C2=A0- parse the packet before pkt_hdr_hash() to select the = RX packets that you need to forward to the host TX ring, and modify the for= warding logic to perform this task.
=C2=A0- modify the logic = of the lb poll() loop so that it also performs the forwarding from host RX = rings to NIC TX rings
I'm not sure that you would have an= y advantages by choosing this path.

Cheers,
<= div>=C2=A0 Vincenzo
Il giorno dom 18 set 2022 alle ore 23:47 Kim Shrier <= kim@westryn.net>= ; ha scritto:
I = have a network monitoring program and I am using the lb app from
netmap to distribute packets to netmap pipes.=C2=A0 The monitor processes are successfully receiving packets.

I would like to modify lb to send some packets to the host stack and
have packets coming from the host stack go out on the monitoring
ethernet interface.

I am relatively new to using netmap and it is not obvious to me how
to properly send/receive some packets to the host tx/rx rings while
still letting the the netmap pipes forward packets to my monitoring
application.

I have looked at the bridge app from netmap which opens 2 netmap
ports. It does not seem to me that that would be the right way to
deal with the host stack in the context of lb.

Should I just process the last tx/rx ring differently from the first ones that are forwarding packets to the netmap pipes?

Thanks,
Kim



--0000000000006fd98c05e996b15d--