Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Hi Techi, let me try to help you. Inline please :) *Regards*, Mrityunjay Kumar. Mobile: +91 - 9731528504 On Sat, Aug 15, 2020 at 12:16 AM wrote: > [Edited Message Follows] > Hello all, Thank you for your inputs. > > Let me elaborate my use case. I currently have DPDK router pipeline where > DPDK-APP-A controls intel NICs through DPDK drivers. DPDK-APP-A is also > responsible for routing between multiple physical interfaces(NICs). > DPDK-APP-B is a packet inspection application which does not have(need) > control over NICs and hence receives packets from DPDK rte_ring(s). > Current working > After rx on NICs, DPDK-APP-A sends packets(after > processing for defrag, conntrack) to DPDK-APP-B through rte_ring and waits > for packets on rte_ring (DPDK-APP-B should send them back after > inspection). Once packets are received through rte_ring then DPDK-APP-A > sends them out through one of the chosen NICs (according to destination > address). This operation is inline i.e. if APP-B wants to drop some > packets, it can, so that packets won't traverse further through APP-A. > > APP-B does not listen/wait on any particular address since it needs to > inspect all the traffic. > Now I want to replace DPDK-APP-A with VPP(DPDK) and need a mechanism with > inline support to send packets to APP-B for inspection. VPP standalone is > working perfectly with my NAT, static routing etc requirements. > [MJ]: from [your dpdk-app as part of vpp]-> send IP offset to APP-B. [do xyz in app-B], when sending back tx on memif as IP packet towards VPP [No MAC address required]. vpp will take care about ARP and l2 header stuff. > > I have explored VPP-plugins a bit but APP-B won't fit as plugin (.so) for > some internal reasons. Hence I started looking into memif (shared memory > packet interfaces) > [MJ] : you can look on VPP process node, Hope this input is helpful if you are planning to add APP-B as part of VPP. :) > > Hope this clears my requirement. > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17239): https://lists.fd.io/g/vpp-dev/message/17239 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
[Edited Message Follows] Hello all, Thank you for your inputs. Let me elaborate my use case. I currently have DPDK router pipeline where DPDK-APP-A controls intel NICs through DPDK drivers. DPDK-APP-A is also responsible for routing between multiple physical interfaces(NICs). DPDK-APP-B is a packet inspection application which does not have(need) control over NICs and hence receives packets from DPDK rte_ring(s). Current working > After rx on NICs, DPDK-APP-A sends packets(after processing for defrag, conntrack) to DPDK-APP-B through rte_ring and waits for packets on rte_ring (DPDK-APP-B should send them back after inspection). Once packets are received through rte_ring then DPDK-APP-A sends them out through one of the chosen NICs (according to destination address). This operation is inline i.e. if APP-B wants to drop some packets, it can, so that packets won't traverse further through APP-A. APP-B does not listen/wait on any particular address since it needs to inspect all the traffic. Now I want to replace DPDK-APP-A with VPP(DPDK) and need a mechanism with inline support to send packets to APP-B for inspection. VPP standalone is working perfectly with my NAT, static routing etc requirements. I have explored VPP-plugins a bit but APP-B won't fit as plugin (.so) for some internal reasons. Hence I started looking into memif (shared memory packet interfaces) Hope this clears my requirement. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17238): https://lists.fd.io/g/vpp-dev/message/17238 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Hello all, Thank you for your inputs. Let me elaborate my use case. I currently have DPDK router pipeline where DPDK-APP-A controls intel NICs through DPDK drivers. DPDK-APP-A is also responsible for routing between multiple physical interfaces(NICs). DPDK-APP-B is a packet inspection application which does not have(need) control over NICs and hence receives packets from DPDK rte_ring(s). Current working > After rx on NICs, DPDK-APP-A sends packets(after processing for defrag, conntrack) to DPDK-APP-B through rte_ring and waits for packets on rte_ring (DPDK-APP-B should send them back after inspection). Once packets are received through rte_ring then DPDK-APP-A sends them out through one of the chosen NICs (according to destination address). This operation is inline i.e. if APP-B wants to drop some packets, it can. APP-B does not listen/wait on any particular address since it needs to inspect all the traffic. Now I want to replace DPDK-APP-A with VPP(DPDK) and need a mechanism to send packets to APP-B for inspection. I have explored VPP-plugins a bit but APP-B won't fit as plugin (.so) for some internal reasons. Hence I started looking into memif (shared memory packet interfaces) Hope this clears my requirement. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17238): https://lists.fd.io/g/vpp-dev/message/17238 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Hi Techiek *If you are clear about routing & Networking then below is the advice that can work for you.* *Create mem interface in IP mode. when you are sending n/w packet from your non-vpp application to vpp, send an IP packet on mem interface. rest thing VPP will take care. * *Hope this will work for you. * *:)* *//MJ * *Regards*, Mrityunjay Kumar. Mobile: +91 - 9731528504 On Mon, Aug 10, 2020 at 11:03 AM wrote: > Hello Team, > > How do I send packets out on a physical interface after I received them > through libmemif in non-vpp application from VPP(DPDK)? Do I need to send > them back to vpp so that VPP can send them out on a physical interface. > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17236): https://lists.fd.io/g/vpp-dev/message/17236 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
> How libmemif is supposed to be used then ? Did you get a chance to look > into use case above ? As poited by Neale you should not set 192.168.1.1 on memif/0/0 and use it as next hop at the same time. Memif are just interfaces. You can set addresses, route traffic etc., but you need to abide by how ip routing works. Memif is no different than any kind of other interfaces. What are you trying to achieve? What is the app on the other end of memif is expecting? If you app is answering to 192.168.1.1, then maybe you should just set 192.168.1.2 on memif/0/0. ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17230): https://lists.fd.io/g/vpp-dev/message/17230 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Hello Neale Ranns, How libmemif is supposed to be used then ? Did you get a chance to look into use case above ? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17229): https://lists.fd.io/g/vpp-dev/message/17229 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
[Edited Message Follows] 172.16.16.18 and 172.16.82.247 are IP addresses assigned to vpp physical interfaces. 172.16.16.17 and 172.16.82.4 are hosts(different machines) attached to those interfaces. VPP is acting as router. That works perfectly. Now I just want to let some non-vpp application to read packets. Hence using memif. Below is total config. vppctl create interface memif id 0 master vppctl set int state memif0/0 up vppctl ip table add 1 vppctl set interface table memif0/0 1 vppctl set int ip address memif0/0 192.168.1.1/24 vppctl set interface state GigabitEthernet3/0/0 up vppctl set interface state GigabitEthernet4/0/0 up vppctl set interface ip address GigabitEthernet4/0/0 172.16.16.18/24 vppctl set interface ip address GigabitEthernet3/0/0 172.16.82.247/24 vppctl ip route add 172.16.82.4/32 via 192.168.1.1 next-hop-table 1 ---> removed memif0/0 as per suggestion, VPP itself starts answering to icmp, packet does not reach to memif or original destination vppctl ip route add 172.16.82.4/32 table 1 via GigabitEthernet3/0/0 next-hop-table 0 ---> results in error -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17223): https://lists.fd.io/g/vpp-dev/message/17223 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
172.16.16.18 and 172.16.82.247 are IP addresses assigned to vpp physical interfaces. 172.16.16.17 and 172.16.82.4 are hosts(different machines) attached to those interfaces. VPP is acting as router. That works perfectly. Now I just want to let some non-vpp application to read packets. Hence using memif. Below is total config. vppctl create interface memif id 0 master vppctl set int state memif0/0 up vppctl ip table add 1 vppctl set interface table memif0/0 1 vppctl set int ip address memif0/0 192.168.1.1/24 vppctl set interface state GigabitEthernet3/0/0 up vppctl set interface state GigabitEthernet4/0/0 up vppctl set interface ip address GigabitEthernet4/0/0 172.16.16.18/24 vppctl set interface ip address GigabitEthernet3/0/0 172.16.82.247/24 vppctl ip route add 172.16.82.4/32 via 192.168.1.1 next-hop-table 1 ---> removed memif0/0 as per suggestion vppctl ip route add 172.16.82.4/32 table 1 via GigabitEthernet3/0/0 next-hop-table 0 ---> results in error -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17223): https://lists.fd.io/g/vpp-dev/message/17223 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
You can't use the same address as a nexthop in a route and as an address applied to one of your own interfaces: you can't route to yourself. You might also want to read: https://fd.io/docs/vpp/master/gettingstarted/developers/fib20/attachedexport.html /neale tpyed by my fat tumhbs From: vpp-dev@lists.fd.io on behalf of techi...@gmail.com Sent: Wednesday, August 12, 2020 8:05:56 PM To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif Hello Ben, vppctl create interface memif id 0 master vppctl set int state memif0/0 up vppctl ip table add 1 vppctl set interface table memif0/0 1 vppctl set int ip address memif0/0 192.168.1.1/24 vppctl set interface state GigabitEthernet3/0/0 up vppctl set interface state GigabitEthernet4/0/0 up vppctl set interface ip address GigabitEthernet4/0/0 172.16.16.18/24 vppctl set interface ip address GigabitEthernet3/0/0 172.16.82.247/24 vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0 vppctl ip route add 172.16.82.4/32 table 1 via GigabitEthernet3/0/0 I did above config. It shows blackholed packet error in trace. What am I doing wrong ? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17222): https://lists.fd.io/g/vpp-dev/message/17222 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
> vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0 next- > hop-table 1 > It shows following error: > ip route: parse error `via 192.168.1.1 memif0/0 next-...' My bad, you should remove the interface: vppctl ip route add 172.16.82.4/32 via 192.168.1.1 next-hop-table 1 ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17221): https://lists.fd.io/g/vpp-dev/message/17221 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
On Thu, Aug 13, 2020 at 01:38 AM, Benoit Ganne (bganne) wrote: > > vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0 next-hop-table > 1 It shows following error: ip route: parse error `via 192.168.1.1 memif0/0 next-...' -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17220): https://lists.fd.io/g/vpp-dev/message/17220 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Ok, from what I understand, what you see in the trace is when the packet is entering VPP through DPDK, it matches the route 'vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0' you configured in table 0 (default VRF), so VPP tries to forward it through 192.168.1.1, but this address is programmed only in VRF 1, so VRF 0 does not know it and ARP. Then ARP reply comes back from memif0, but is is looked up in VRF 1 and is dropped (it is waited for in VRF 0). I think you should change your route like this: vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0 next-hop-table 1 vppctl ip route add 172.16.82.4/32 table 1 via GigabitEthernet3/0/0 next-hop-table 0 Best ben > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of > techi...@gmail.com > Sent: jeudi 13 août 2020 10:09 > To: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] #vpp-memif Send packets out on physical interface > controlled by vpp(DPDK) once they are received through memif > > Hi ben, > > Please find below trace (dpdk-input and memif-input) in application I > am just writing back buffers I received on memif.. > > 00:02:56:971957: dpdk-input > GigabitEthernet4/0/0 rx queue 0 > buffer 0x98114: current data 0, length 74, buffer-pool 0, ref-count 1, > totlen-nifb 0, trace handle 0x0 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 1, nb_segs 1, pkt_len 74 > buf_len 2176, data_len 74, ol_flags 0x180, data_off 128, phys_addr > 0x56604580 > packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 > rss 0x0 fdir.hi 0x0 fdir.lo 0x0 > Packet Offload Flags > PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid > PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid > Packet Types > RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers > IP4: a4:bb:6d:0f:bf:56 -> 00:0d:48:49:12:a2 > ICMP: 172.16.16.17 -> 172.16.82.4 > tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN > fragment id 0x7c68 > ICMP echo_request checksum 0x4baf > 00:02:56:971980: ethernet-input > frame: flags 0x3, hw-if-index 2, sw-if-index 2 > IP4: a4:bb:6d:0f:bf:56 -> 00:0d:48:49:12:a2 > 00:02:56:971994: ip4-input-no-checksum > ICMP: 172.16.16.17 -> 172.16.82.4 > tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN > fragment id 0x7c68 > ICMP echo_request checksum 0x4baf > 00:02:56:972001: ip4-lookup > fib 0 dpo-idx 3 flow hash: 0x > ICMP: 172.16.16.17 -> 172.16.82.4 > tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN > fragment id 0x7c68 > ICMP echo_request checksum 0x4baf > 00:02:56:972007: ip4-arp > ICMP: 172.16.16.17 -> 172.16.82.4 > tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN > fragment id 0x7c68 > ICMP echo_request checksum 0x4baf > 00:02:56:972019: ip4-drop > ICMP: 172.16.16.17 -> 172.16.82.4 > tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN > fragment id 0x7c68 > ICMP echo_request checksum 0x4baf > 00:02:56:972083: error-drop > rx:GigabitEthernet4/0/0 > 00:02:56:972088: drop > ip4-arp: ARP requests sent > > Packet 2 > > 00:02:56:972299: memif-input > memif: hw_if_index 3 next-index 4 > slot: ring 0 > 00:02:56:972327: ethernet-input > frame: flags 0x1, hw-if-index 3, sw-if-index 3 > ARP: 02:fe:87:ff:c6:2a -> ff:ff:ff:ff:ff:ff > 00:02:56:972335: arp-input > request, type ethernet/IP4, address size 6/4 > 02:fe:87:ff:c6:2a/192.168.1.1 -> 00:00:00:00:00:00/192.168.1.1 > 00:02:56:972339: arp-reply > request, type ethernet/IP4, address size 6/4 > 02:fe:87:ff:c6:2a/192.168.1.1 -> 00:00:00:00:00:00/192.168.1.1 > 00:02:56:972350: error-drop > rx:memif0/0 > 00:02:56:972351: drop > null-node: blackholed packets -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17219): https://lists.fd.io/g/vpp-dev/message/17219 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Hi ben, Please find below trace (dpdk-input and memif-input) in application I am just writing back buffers I received on memif.. 00:02:56:971957: dpdk-input GigabitEthernet4/0/0 rx queue 0 buffer 0x98114: current data 0, length 74, buffer-pool 0, ref-count 1, totlen-nifb 0, trace handle 0x0 ext-hdr-valid l4-cksum-computed l4-cksum-correct PKT MBUF: port 1, nb_segs 1, pkt_len 74 buf_len 2176, data_len 74, ol_flags 0x180, data_off 128, phys_addr 0x56604580 packet_type 0x11 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0 rss 0x0 fdir.hi 0x0 fdir.lo 0x0 Packet Offload Flags PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid Packet Types RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers IP4: a4:bb:6d:0f:bf:56 -> 00:0d:48:49:12:a2 ICMP: 172.16.16.17 -> 172.16.82.4 tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN fragment id 0x7c68 ICMP echo_request checksum 0x4baf 00:02:56:971980: ethernet-input frame: flags 0x3, hw-if-index 2, sw-if-index 2 IP4: a4:bb:6d:0f:bf:56 -> 00:0d:48:49:12:a2 00:02:56:971994: ip4-input-no-checksum ICMP: 172.16.16.17 -> 172.16.82.4 tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN fragment id 0x7c68 ICMP echo_request checksum 0x4baf 00:02:56:972001: ip4-lookup fib 0 dpo-idx 3 flow hash: 0x ICMP: 172.16.16.17 -> 172.16.82.4 tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN fragment id 0x7c68 ICMP echo_request checksum 0x4baf 00:02:56:972007: ip4-arp ICMP: 172.16.16.17 -> 172.16.82.4 tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN fragment id 0x7c68 ICMP echo_request checksum 0x4baf 00:02:56:972019: ip4-drop ICMP: 172.16.16.17 -> 172.16.82.4 tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN fragment id 0x7c68 ICMP echo_request checksum 0x4baf 00:02:56:972083: error-drop rx:GigabitEthernet4/0/0 00:02:56:972088: drop ip4-arp: ARP requests sent Packet 2 00:02:56:972299: memif-input memif: hw_if_index 3 next-index 4 slot: ring 0 00:02:56:972327: ethernet-input frame: flags 0x1, hw-if-index 3, sw-if-index 3 ARP: 02:fe:87:ff:c6:2a -> ff:ff:ff:ff:ff:ff 00:02:56:972335: arp-input request, type ethernet/IP4, address size 6/4 02:fe:87:ff:c6:2a/192.168.1.1 -> 00:00:00:00:00:00/192.168.1.1 00:02:56:972339: arp-reply request, type ethernet/IP4, address size 6/4 02:fe:87:ff:c6:2a/192.168.1.1 -> 00:00:00:00:00:00/192.168.1.1 00:02:56:972350: error-drop rx:memif0/0 00:02:56:972351: drop null-node: blackholed packets -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17217): https://lists.fd.io/g/vpp-dev/message/17217 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
> I did above config. It shows blackholed packet error in trace. What am I > doing wrong ? Could you share the packet trace? Best ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17216): https://lists.fd.io/g/vpp-dev/message/17216 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Can anyone please check and revert on this config ? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17214): https://lists.fd.io/g/vpp-dev/message/17214 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Hello Ben, I tried below configuration, Packet rx on physical nic are visible in application through memif, and they are written-back successfully to memif. but they are not reaching intended destination. vppctl create interface memif id 0 master vppctl set int state memif0/0 up vppctl set int ip address memif0/0 192.168.1.1/24 vppctl set interface state GigabitEthernet3/0/0 up vppctl set interface state GigabitEthernet4/0/0 up vppctl set interface ip address GigabitEthernet4/0/0 172.16.16.18/24 vppctl set interface ip address GigabitEthernet3/0/0 172.16.82.247/24 vppctl abf policy add id 1 acl 0 via GigabitEthernet3/0/0 vppctl abf attach ip4 policy 1 priority 0 memif0/0 vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17194): https://lists.fd.io/g/vpp-dev/message/17194 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
> But I am having trouble figuring out routing or ABF in former case. Once I > send packet back to VPP after processing from my application, how VPP can > send it out on physical interface. I have two physical interfaces. > Normally packets flow between two using link routes automatically. Both > interfaces have IP address from different subnets. You should be able to use different VRF for each interface: 1 VRF with ABF for physical interfaces (packets rx on physical interfaces will use ABF to select destination) and another "classic" VRF for memif interfaces (packets rx on memif interfaces wil use classic LPM routing). Best ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17178): https://lists.fd.io/g/vpp-dev/message/17178 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
[Edited Message Follows] Thanks. But I am having trouble figuring out routing or ABF in former case. Once I send packet back to VPP after processing from my application, how VPP can send it out on physical interface. I have two physical interfaces. Normally packets flow between two using link routes automatically. Both interfaces have IP address from different subnets. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17177): https://lists.fd.io/g/vpp-dev/message/17177 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Thanks. But I am having trouble figuring out routing or ABF in former case. Once I send packet back to VPP after processing from my application, how VPP can send it out on physical interface. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17177): https://lists.fd.io/g/vpp-dev/message/17177 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
> How do I send packets out on a physical interface after I received them > through libmemif in non-vpp application from VPP(DPDK)? Do I need to send > them back to vpp so that VPP can send them out on a physical interface. If the physical interface is managed by VPP, yes, as you cannot share physical interfaces. Otherwise you have the option to manage the physical interface directly from your app with eg. DPDK. Best ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17176): https://lists.fd.io/g/vpp-dev/message/17176 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Hello Team, How do I send packets out on a physical interface after I received them through libmemif in non-vpp application from VPP(DPDK)? Do I need to send them back to vpp so that VPP can send them out on a physical interface. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17174): https://lists.fd.io/g/vpp-dev/message/17174 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
