Re: [vpp-dev] Memory leak in map plugin

2021-11-17 Thread Benoit Ganne (bganne) via lists.fd.io
Hi Ben,

Thanks for the detailed report, you are correct we are missing a vec_free() 
before returning from the function.
Can you give a try to https://gerrit.fd.io/r/c/vpp/+/34536 ?

Best
ben

> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Ben McKeegan
> Sent: mardi 16 novembre 2021 15:04
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Memory leak in map plugin
> 
> Hello,
> 
> I have identified a memory leak the ip4_map function of
> src/plugins/ip4_map.c.  I am using the 21.10 release.
> 
> Enabling memory trace of the main-heap via the debug CLI and backtracing
> with gdb both point to all the leaked memory being allocated from the
> vec_add1(buffer0,pi0) macro at line 293 of ip4_map.c.   In tests it is
> leaking approximately 50 bytes for every packet passing through this
> function (invariant on packet size).
> 
> Here is an extract of the relevant code:
> 
>   exit:
> /* Send fragments that were added in the frame */
> if (free_original_buffer0)
>   {
> vlib_buffer_free_one (vm, pi0);   /* Free original packet */
>   }
> else
>   {
> vec_add1 (buffer0, pi0);    leak is here on line 293
>   }
> 
> frag_from0 = buffer0;
> frag_left0 = vec_len (buffer0);
> 
> while (frag_left0 > 0)
>   {
> while (frag_left0 > 0 && n_left_to_next > 0)
>   {
> u32 i0;
> i0 = to_next[0] = frag_from0[0];
> frag_from0 += 1;
> frag_left0 -= 1;
> to_next += 1;
> n_left_to_next -= 1;
> 
> vlib_get_buffer (vm, i0)->error =
>   error_node->errors[error0];
> vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
>  to_next, n_left_to_next,
>  i0, next0);
>   }
> vlib_put_next_frame (vm, node, next_index, n_left_to_next);
> vlib_get_next_frame (vm, node, next_index, to_next,
>  n_left_to_next);
>   }
> vec_reset_length (buffer0);
>   }
>vlib_put_next_frame (vm, node, next_index, n_left_to_next);
> 
> 
> I must admit I do not fully understand exactly what this code is doing,
> but I am suspicious of the use of 'vec_reset_length' macro.   I have
> looked at the definition of this and it appears that although this sets
> the length of the vector back to zero (if the pointer is non-zero), it
> does not release any memory that may have been allocated.   Do we not
> need a call to 'vec_free' somewhere?
> 
> Regards,
> Ben.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20503): https://lists.fd.io/g/vpp-dev/message/20503
Mute This Topic: https://lists.fd.io/mt/87095064/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 Linux-cp plugin with multicast packets

2021-11-17 Thread Neale Ranns
[Adding the public mailer so we all benefit]

Hi Wei,

You need to add the multicast routes to VPP too.

/neale

From: Wei Huang 
Date: Wednesday, 17 November 2021 at 03:57
To: nra...@cisco.com , Neale Ranns 
Subject: VPP Linux-cp plugin with multicast packets
Hi Neale

I am using the linux-cp plugin you created in VPP (v21.06) and run into issues 
with multicast packet from OSPF.
I try to make FRR work with VPP.  I created a lcp pair to an interface used to 
connect to other router using OSPF.

FRR--VPP (192.168.100.5)--Router (192.168.100.20)
VPP2   ETH2ETH1
When I do tshark on Router ETH1, I can see hello packets from both sides, i.e. 
192.168.100.5->224.0.0.5 and 192.168.100.20->224.0.0.5.
But when do tshark on VPP2, I can only see hello packets from 
192.168.100.5->224.0.0.5. Seems VPP didn't forward multicast packets to VPP2.
When I do packet trace, this is what I got:
01:21:34:796763: dpdk-input
  tn-eth2 rx queue 0
  buffer 0x93b1f: current data 0, length 82, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 2, nb_segs 1, pkt_len 82
buf_len 2176, data_len 82, ol_flags 0x0, data_off 128, phys_addr 0xb20ec840
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
  IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05
  OSPF: 192.168.100.20 -> 224.0.0.5
tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
fragment id 0xc2dc
01:21:34:796805: ethernet-input
  frame: flags 0x1, hw-if-index 3, sw-if-index 3
  IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05
01:21:34:796836: ip4-input
  OSPF: 192.168.100.20 -> 224.0.0.5
tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
fragment id 0xc2dc
01:21:34:796842: ip4-mfib-forward-lookup
  fib 0 entry 0
01:21:34:796846: ip4-mfib-forward-rpf
  entry 0 itf -1 flags
01:21:34:796847: ip4-drop
OSPF: 192.168.100.20 -> 224.0.0.5
  tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
  fragment id 0xc2dc
01:21:34:796849: error-drop
  rx:tn-eth2
01:21:34:796853: drop
  ip4-input: Multicast RPF check failed

Do I need to do anything special for multicast packets?

Regards,

Wei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20504): https://lists.fd.io/g/vpp-dev/message/20504
Mute This Topic: https://lists.fd.io/mt/87116971/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 20.05 problems related to memory allocations -- possible memory leak?

2021-11-17 Thread Elias Rudberg
Hello Murthy,

I think that the problem with VPP 20.05 that I wrote about back in
October 2020 later turned out to be related to NAT44 hairpinning, see
the discussion here: https://lists.fd.io/g/vpp-dev/topic/78662322

A fix was merged so the exact same problem should not happen for the
21.06 version that you are using.

If you have some similar problem in the sense that VPP runs out of
memory for some unknown reason, then my advice would be to gather as
much statistics as you can (error counters and so on) from around the
time the problem happens, to see if that gives you any clue.

Best regards,
Elias


On Tue, 2021-11-16 at 23:10 -0800, Satya Murthy wrote:
> Hi Klemant/Elias/Vpp-Experts,
> 
> We are also seeing the same crash with fdio 21.06 version.
> 
> vec_resize_allocate_memory + 0x285
> vlib_put_next_frame + 0xbd
> 
> Our main-heap size is set to 2G.
> 
> Is this a known issue (or) any fix that is available for this.
> 
> Any inputs will be helpful.
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20505): https://lists.fd.io/g/vpp-dev/message/20505
Mute This Topic: https://lists.fd.io/mt/77479819/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 Linux-cp plugin with multicast packets

2021-11-17 Thread Wei Huang
Thanks for reply. I'm new to VPP, can you give more details on how I add 
multicast routes to VPP? Change in code to register for multicast packets or 
using CLI to configure it?

Wei

From: Neale Ranns 
Sent: Wednesday, November 17, 2021 6:08 AM
To: Wei Huang ; vpp-dev@lists.fd.io 

Subject: [External] : Re: VPP Linux-cp plugin with multicast packets


[Adding the public mailer so we all benefit]



Hi Wei,



You need to add the multicast routes to VPP too.



/neale



From: Wei Huang 
Date: Wednesday, 17 November 2021 at 03:57
To: nra...@cisco.com , Neale Ranns 
Subject: VPP Linux-cp plugin with multicast packets

Hi Neale



I am using the linux-cp plugin you created in VPP (v21.06) and run into issues 
with multicast packet from OSPF.

I try to make FRR work with VPP.  I created a lcp pair to an interface used to 
connect to other router using OSPF.



FRR--VPP (192.168.100.5)--Router (192.168.100.20)

VPP2   ETH2ETH1

When I do tshark on Router ETH1, I can see hello packets from both sides, i.e. 
192.168.100.5->224.0.0.5 and 192.168.100.20->224.0.0.5.

But when do tshark on VPP2, I can only see hello packets from 
192.168.100.5->224.0.0.5. Seems VPP didn't forward multicast packets to VPP2.

When I do packet trace, this is what I got:

01:21:34:796763: dpdk-input

  tn-eth2 rx queue 0

  buffer 0x93b1f: current data 0, length 82, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x0

  ext-hdr-valid

  l4-cksum-computed l4-cksum-correct

  PKT MBUF: port 2, nb_segs 1, pkt_len 82

buf_len 2176, data_len 82, ol_flags 0x0, data_off 128, phys_addr 0xb20ec840

packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0

rss 0x0 fdir.hi 0x0 fdir.lo 0x0

  IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05

  OSPF: 192.168.100.20 -> 224.0.0.5

tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN

fragment id 0xc2dc

01:21:34:796805: ethernet-input

  frame: flags 0x1, hw-if-index 3, sw-if-index 3

  IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05

01:21:34:796836: ip4-input

  OSPF: 192.168.100.20 -> 224.0.0.5

tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN

fragment id 0xc2dc

01:21:34:796842: ip4-mfib-forward-lookup

  fib 0 entry 0

01:21:34:796846: ip4-mfib-forward-rpf

  entry 0 itf -1 flags

01:21:34:796847: ip4-drop

OSPF: 192.168.100.20 -> 224.0.0.5

  tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN

  fragment id 0xc2dc

01:21:34:796849: error-drop

  rx:tn-eth2

01:21:34:796853: drop

  ip4-input: Multicast RPF check failed



Do I need to do anything special for multicast packets?



Regards,



Wei

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20506): https://lists.fd.io/g/vpp-dev/message/20506
Mute This Topic: https://lists.fd.io/mt/87116971/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 Linux-cp plugin with multicast packets

2021-11-17 Thread Petr Boltík
Hi,

there is no multicast route to the local Forward ... solution:
https://lists.fd.io/g/vpp-dev/topic/83103366#19478

Petr

Dne st 17. 11. 2021 14:41 uživatel Wei Huang 
napsal:

> Thanks for reply. I'm new to VPP, can you give more details on how I add
> multicast routes to VPP? Change in code to register for multicast packets
> or using CLI to configure it?
>
> Wei
> --
> *From:* Neale Ranns 
> *Sent:* Wednesday, November 17, 2021 6:08 AM
> *To:* Wei Huang ; vpp-dev@lists.fd.io <
> vpp-dev@lists.fd.io>
> *Subject:* [External] : Re: VPP Linux-cp plugin with multicast packets
>
>
> [Adding the public mailer so we all benefit]
>
>
>
> Hi Wei,
>
>
>
> You need to add the multicast routes to VPP too.
>
>
>
> /neale
>
>
>
> *From: *Wei Huang 
> *Date: *Wednesday, 17 November 2021 at 03:57
> *To: *nra...@cisco.com , Neale Ranns <
> ne...@graphiant.com>
> *Subject: *VPP Linux-cp plugin with multicast packets
>
> Hi Neale
>
>
>
> I am using the linux-cp plugin you created in VPP (v21.06) and run into
> issues with multicast packet from OSPF.
>
> I try to make FRR work with VPP.  I created a lcp pair to an interface
> used to connect to other router using OSPF.
>
>
>
> FRR--VPP (192.168.100.5)--Router (192.168.100.20)
>
> VPP2   ETH2ETH1
>
> When I do tshark on Router ETH1, I can see hello packets from both sides,
> i.e. 192.168.100.5->224.0.0.5 and 192.168.100.20->224.0.0.5.
>
> But when do tshark on VPP2, I can only see hello packets from
> 192.168.100.5->224.0.0.5. Seems VPP didn't forward multicast packets to
> VPP2.
>
> When I do packet trace, this is what I got:
>
> 01:21:34:796763: dpdk-input
>
>   tn-eth2 rx queue 0
>
>   buffer 0x93b1f: current data 0, length 82, buffer-pool 0, ref-count 1,
> totlen-nifb 0, trace handle 0x0
>
>   ext-hdr-valid
>
>   l4-cksum-computed l4-cksum-correct
>
>   PKT MBUF: port 2, nb_segs 1, pkt_len 82
>
> buf_len 2176, data_len 82, ol_flags 0x0, data_off 128, phys_addr
> 0xb20ec840
>
> packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
>
> rss 0x0 fdir.hi 0x0 fdir.lo 0x0
>
>   IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05
>
>   OSPF: 192.168.100.20 -> 224.0.0.5
>
> tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
>
> fragment id 0xc2dc
>
> 01:21:34:796805: ethernet-input
>
>   frame: flags 0x1, hw-if-index 3, sw-if-index 3
>
>   IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05
>
> 01:21:34:796836: ip4-input
>
>   OSPF: 192.168.100.20 -> 224.0.0.5
>
> tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
>
> fragment id 0xc2dc
>
> 01:21:34:796842: ip4-mfib-forward-lookup
>
>   fib 0 entry 0
>
> 01:21:34:796846: ip4-mfib-forward-rpf
>
>   entry 0 itf -1 flags
>
> 01:21:34:796847: ip4-drop
>
> OSPF: 192.168.100.20 -> 224.0.0.5
>
>   tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
>
>   fragment id 0xc2dc
>
> 01:21:34:796849: error-drop
>
>   rx:tn-eth2
>
> 01:21:34:796853: drop
>
>   ip4-input: Multicast RPF check failed
>
>
>
> Do I need to do anything special for multicast packets?
>
>
>
> Regards,
>
>
>
> Wei
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20507): https://lists.fd.io/g/vpp-dev/message/20507
Mute This Topic: https://lists.fd.io/mt/87116971/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [External] : Re: [vpp-dev] VPP linux-cp plugin with multicast packets

2021-11-17 Thread Wei Huang
Thanks a lot. This helps.

Wei

From: Petr Boltík 
Sent: Wednesday, November 17, 2021 2:14 AM
To: Wei Huang 
Cc: vpp-dev@lists.fd.io 
Subject: [External] : Re: [vpp-dev] VPP linux-cp plugin with multicast packets

Hi,

there is no multicast route to the local Forward ... solution:
https://lists.fd.io/g/vpp-dev/topic/83103366#19478

PetrB.

st 17. 11. 2021 v 4:08 odesílatel Wei Huang 
mailto:wei.hu.hu...@oracle.com>> napsal:
I am using the linux-cp plugin in VPP (v21.06) and run into issues with 
multicast packet from OSPF.
I try to make FRR work with VPP.  I created a lcp pair (ETH2-VPP2), ETH2 
directly connect to router using OSPF.

FRR--VPP (192.168.100.5)--Router (192.168.100.20)
VPP2   ETH2ETH1

vppctl lcp create tn-eth2 host-if vpp2 netns t3-tap-ns
ip netns exec t3-tap-ns ip addr add 
192.168.100.5/24
 dev vpp2
ip netns exec t3-tap-ns ip link set dev vpp2 up


When I do tshark on Router ETH1, I can see hello packets from both sides, i.e. 
192.168.100.5->224.0.0.5 and 192.168.100.20->224.0.0.5.
But when do tshark on VPP2, I can only see hello packets from 
192.168.100.5->224.0.0.5. Seems VPP didn't forward multicast packets to VPP2.
When I do packet trace, this is what I got:
01:21:34:796763: dpdk-input
  tn-eth2 rx queue 0
  buffer 0x93b1f: current data 0, length 82, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x0
  ext-hdr-valid
  l4-cksum-computed l4-cksum-correct
  PKT MBUF: port 2, nb_segs 1, pkt_len 82
buf_len 2176, data_len 82, ol_flags 0x0, data_off 128, phys_addr 0xb20ec840
packet_type 0x0 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
  IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05
  OSPF: 192.168.100.20 -> 224.0.0.5
tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
fragment id 0xc2dc
01:21:34:796805: ethernet-input
  frame: flags 0x1, hw-if-index 3, sw-if-index 3
  IP4: fa:16:3f:a9:2c:cc -> 01:00:5e:00:00:05
01:21:34:796836: ip4-input
  OSPF: 192.168.100.20 -> 224.0.0.5
tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
fragment id 0xc2dc
01:21:34:796842: ip4-mfib-forward-lookup
  fib 0 entry 0
01:21:34:796846: ip4-mfib-forward-rpf
  entry 0 itf -1 flags
01:21:34:796847: ip4-drop
OSPF: 192.168.100.20 -> 224.0.0.5
  tos 0xc0, ttl 1, length 68, checksum 0xf102 dscp CS6 ecn NON_ECN
  fragment id 0xc2dc
01:21:34:796849: error-drop
  rx:tn-eth2
01:21:34:796853: drop
  ip4-input: Multicast RPF check failed

Do I need to do anything special for multicast packets to be directed to the 
TAP interface?

Regards,

Wei





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20508): https://lists.fd.io/g/vpp-dev/message/20508
Mute This Topic: https://lists.fd.io/mt/87121477/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[vpp-dev] VPP release 21.10.1 artifacts are available on packagecloud.io

2021-11-17 Thread Andrew Yourtchenko
Hi all,

VPP release 21.10.1 artifacts are available at packagecloud.io/fdio/release.

Thanks a lot to Dave Wallace and Vanessa Valderrama for the help! 

--a

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20509): https://lists.fd.io/g/vpp-dev/message/20509
Mute This Topic: https://lists.fd.io/mt/87128508/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 release 21.10.1 artifacts are available on packagecloud.io

2021-11-17 Thread Jerome Tollet via lists.fd.io
Congratulations !

Le 17/11/2021 21:09, « vpp-dev@lists.fd.io au nom de Andrew Yourtchenko » 
 a écrit :

Hi all,

VPP release 21.10.1 artifacts are available at packagecloud.io/fdio/release.

Thanks a lot to Dave Wallace and Vanessa Valderrama for the help! 

--a


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20510): https://lists.fd.io/g/vpp-dev/message/20510
Mute This Topic: https://lists.fd.io/mt/87128508/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[vpp-dev] [Bug or Not] QoS l2-policer-classify match question #vpp_qos

2021-11-17 Thread Smith Beirvin
Hi VPP fellows:
Recently I try to do the qos rate limit based on loop port(used for ESP/VxLAN 
encapspulation). But I found that "l2-policer-classify" node wouldn't hit the 
packet, by contrast, acl match can work fine.So I track the source code for 
"l2-policer-classify" node fucntion "policer_classify_inline", it use "h0 = 
b0->data;" to do some match action, however I think it should use "h0 = (u8 *) 
vlib_buffer_get_current (b0);" to do corresponding match action. By the way, 
"l2-input-acl" node function "l2_in_out_acl_node_fn" also use "h0 = (u8 *) 
vlib_buffer_get_current (b0);" to do corresponding match action. So I modified 
the "policer_classify_inline" function source code as below, Then it work fine.
*So I wonder this is a bug or I didn't configure the VPP Qos use the correct 
step? Hope get a reply from VPP fellows.*

1.Qos Limit rate to 800kbps configuration:
configure policer name policy1 cir 800 cb 9 rate kbps round closest type 
1r2c conform-action transmit exceed-action drop
classify table mask l3 ip4 src proto
classify session policer-hit-next policy1 exceed-color table-index 0 match l3 
ip4 src 10.100.0.176 proto 50
set policer classify interface loop48 l2-table 0

2. ACL Deny configuration
classify table mask l3 ip4 src proto
classify session acl-hit-next deny table-index 1 match l3 ip4 src 10.100.0.176 
proto 50
set int input acl intfc loop48 l2-table 1

3.show interface features loop48
l2-input:
POLICER_CLAS (l2-policer-classify)
ACL (l2-input-acl)
FWD (l2-fwd)
UU_FLOOD (l2-flood)
ARP_TERM (arp-term-l2bd)
FLOOD (l2-flood)
4. "policer_classify_inline" source code modification:
diff --git a/src/vnet/policer/node_funcs.c b/src/vnet/policer/node_funcs.c
index fd7f197e9..bdbb17087 100644
--- a/src/vnet/policer/node_funcs.c
+++ b/src/vnet/policer/node_funcs.c
@@ -559,11 +559,17 @@ policer_classify_inline (vlib_main_t * vm,

bi0 = from[0];
b0 = vlib_get_buffer (vm, bi0);
-  h0 = b0->data;

bi1 = from[1];
b1 = vlib_get_buffer (vm, bi1);
+
+#if 0 /* modified by liuman for policer match */
+  h0 = b0->data;
h1 = b1->data;
+#else
+  h0 = (u8 *) vlib_buffer_get_current (b0);
+  h1 = (u8 *) vlib_buffer_get_current (b1);
+#endif

sw_if_index0 = vnet_buffer (b0)->sw_if_index[VLIB_RX];
table_index0 =
@@ -606,7 +612,11 @@ policer_classify_inline (vlib_main_t * vm,

bi0 = from[0];
b0 = vlib_get_buffer (vm, bi0);
+#if 0 /* modified by liuman for policer match */
h0 = b0->data;
+#else
+  h0 = (u8 *) vlib_buffer_get_current (b0);
+#endif

sw_if_index0 = vnet_buffer (b0)->sw_if_index[VLIB_RX];
table_index0 =
@@ -673,7 +683,11 @@ policer_classify_inline (vlib_main_t * vm,
n_left_to_next -= 1;

b0 = vlib_get_buffer (vm, bi0);
- h0 = b0->data;
+#if 0 /* modified by liuman for policer match */
+  h0 = b0->data;
+#else
+ h0 = (u8 *) vlib_buffer_get_current (b0);
+#endif
table_index0 = vnet_buffer (b0)->l2_classify.table_index;
e0 = 0;
t0 = 0;

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20511): https://lists.fd.io/g/vpp-dev/message/20511
Mute This Topic: https://lists.fd.io/mt/87137335/21656
Mute #vpp_qos:https://lists.fd.io/g/vpp-dev/mutehashtag/vpp_qos
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-