Re: [ovs-discuss] How to store the tcp_src or tcp_dst field value in a variable and then print in vlogs?

2019-02-20 Thread Flavio Leitner
On Tue, Feb 19, 2019 at 12:43:08PM +0800, Krish wrote:
> Hi Flavio,
> 
> I think I got tcp_src and tcp_dst values, I can also successfully print
> them.
> Here is what I did:
> for(numb=0;numb {
> 
> uint8_t nw_proto = 0;
> packet=packets->packets[numb];
> size_t size = dp_packet_size(packet);
> const void *data = dp_packet_data(packet);
> const char *frame = (const char *)data;
> dp_packet_reset_offsets(packet);
> *data_pull(&data, &size, ETH_ADDR_LEN * 2);*
> //dl_type = parse_ether(&data, &size);
> //VLOG_DBG("parse ether type DL TYPE: 0x%4x", dl_type);
> packet->l3_ofs = (char *)data - frame;
> const struct ip_header *ip = dp_packet_l3(packet);
> nw_proto = ip->ip_proto;
> VLOG_DBG("IP proto---> %d ", nw_proto);
> int ip_len;
> ip_len = IP_IHL(ip->ip_ihl_ver) * 4;
> 
> *data_pull(&data, &size, ip_len);*
> packet->l4_ofs = (char *)data - frame;
> if(nw_proto == 6)
> {
> struct tcp_header *th = dp_packet_l4(packet);
> VLOG_DBG( "tcp_src ---> %d", ntohs(th->tcp_src));
> VLOG_DBG( "tcp_dst ---> %d", ntohs(th->tcp_dst));
>   }
> }
> 
> 
> Can you please confirm, if this is the right approach I have used and not
> seeing the old values like before?

It's hard to read code using html (bold, etc), could you please use
text only and indent the code properly? It makes our life a lot easier.

When you pull ETH_ADDR_LEN*2, the offset now points to ethernet_type
which is not the l3_ofs as you set next. I don't think the above code
works unless you uncomment parse_ethertype() which pulls more 4 bytes.

fbl



> 
> Thank you so much,
> Krish
> 
> On Tue, Feb 19, 2019 at 11:25 AM Krish  wrote:
> 
> > Flavio,
> >
> > Thank you for the clarification. You explained it very well.
> >
> > I don't want to wait for the miniflow_extraction, so I am left with
> > parsing packet myself.
> >
> > Here is what I am doing now:
> >
> > for(numb=0;numb > {
> >
> > uint8_t nw_proto;
> > const char *frame;
> > packet=packets->packets[numb];
> > const void *data = dp_packet_data(packet);
> > frame = data;
> > *dp_packet_reset_offsets(packet);*
> > * packet->l3_ofs = (char *)data - frame;*
> > * const struct ip_header *ip = dp_packet_l3(packet);*
> > nw_proto = ip->ip_proto;
> > VLOG_DBG("IP proto---> %d ", nw_proto); // This is 0
> >
> > }
> >
> > I followed almost the same approach of what is going in miniflow_extract.
> > nw_proto(ip protocol) is printing out to be 0.
> > I am using this code just before emc_processing and inside
> > dp_netdev_input__.
> > Can you please help me here?
> >
> > Thanks
> > Krish
> >
> >
> > On Mon, Feb 18, 2019 at 8:11 PM Flavio Leitner  wrote:
> >
> >> On Mon, Feb 18, 2019 at 11:05:53AM +0800, Krish wrote:
> >> > Thanks for reply Ben.
> >> > Does it mean that *miniflow_extract* will also initialize the L3 header
> >> > pointer?
> >>
> >> If you look at the miniflow_extract(), you  will see that it calls
> >> dp_packet_reset_offsets(packet) which will set all the header pointers
> >> to their defaults meaning that they are not pointing to anything real.
> >>
> >> These pointers are used by dp_packet_l3 (or 4) functions to locate
> >> the header.
> >>
> >> Then if you continue following the function, you will notice that
> >> the code parses the packet from the outer header to the inner header
> >> and as the parser goes, it updates the header offsets, like this line:
> >>
> >> packet->l3_ofs = (char *)data - frame;
> >>
> >> At this point, you have the pointer to the l3 header and you could use
> >> dp_packet_l3().
> >>
> >>
> >> > But I am getting the correct values for *nw_proto* from the L3 header.
> >> > struct ip_header *ip = dp_packet_l3(packet);
> >> > nw_proto = ip->ip_proto;
> >> >
> >> > Any comments on this? Whether its right or wrong?
> >>
> >> When using DPDK, the packet is represented by two parts. One if the
> >> rte buffer (packet data) that comes from DPDK library and the second
> >> part is the packet's metadata (the offsets you need). This offsets
> >> are allocated in the stack at dp_netdev_process_rxq_port(), so most
> >> probably you are seeing old values from previous packets which
> >> happens to work, but they are not correct.
> >>
> >> As I said above miniflow_extract() initializes those offsets to a
> >> known state and then parse the packet to update with the correct
> >> values.
> >>
> >> In summary, you will need to either wait for miniflow_extract() or
> >> parse the packet yourself if you need the tcp port.
> >>
> >> HTH,
> >> fbl
> >>
> >>
> >>
> >> >
> >> > Thanks a lot for your patience and response.
> >> >
> >> > Regards
> >> >
> >> > Krish
> >> >
> >> > On Sat, Feb 16, 2019 at 10:09 AM Ben Pfaff  wrote:
> >> >
> >> > > You are almost certainly dereferencing a null pointer.
> >> > >
> >> > > On Sat, Feb 16, 2019 at 09:02:17AM +0800, Krish wrote:
> >> > > > That code I showed before. It is working fine and crashing only
> >> when I
> >> > > > enable debugging.
> >> > > >
> >> > > > As *sruct tcp_header's tcp_sr

[ovs-discuss] ovs-vswitchd process huge memory consumption

2019-02-20 Thread Oleg Bondarev
Hi,

OVS 2.8.0, uptime 197 days, 44G RAM.
ovs-appctl memory/show reports:
"handlers:35 ofconns:4 ports:73 revalidators:13 rules:1099 udpif
keys:686"

Similar data on other nodes of the OpenStack cluster.
Seems usage grows gradually over time.
Are there any known issues, like
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14970?
Please advise on the best way to debug.

Thanks,
Oleg
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


Re: [ovs-discuss] ovs-vswitchd process huge memory consumption

2019-02-20 Thread Oleg Bondarev
Ah, sorry, I missed "ovs-vswitchd memory consumption behavior" thread.
So I guess I'm also interested in the scripts for analyzing the heap in a
core dump :)

Thanks,
Oleg

On Wed, Feb 20, 2019 at 7:00 PM Oleg Bondarev 
wrote:

> Hi,
>
> OVS 2.8.0, uptime 197 days, 44G RAM.
> ovs-appctl memory/show reports:
> "handlers:35 ofconns:4 ports:73 revalidators:13 rules:1099 udpif
> keys:686"
>
> Similar data on other nodes of the OpenStack cluster.
> Seems usage grows gradually over time.
> Are there any known issues, like
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14970?
> Please advise on the best way to debug.
>
> Thanks,
> Oleg
>
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss