Re: [dpdk-users] General Questions

[Shyam Shrivastav]

>From my experience as dpdk user

On Thu, Apr 9, 2020 at 11:41 AM Cristofer Martins <
cristofermart...@hotmail.com> wrote:

> Well the reason i thought about using dpdk(together with a user space tcp
> stack) is because my tcp code spend so much time with syscalls that
> removing that would allow better throughput and latency. Is this a valid
> reason? My software runs in single core(and most of time in cheap vps) so i
> want to extract the best i can from them.
>

Yes using dpdk instead of getting packets from kernel stack increases
performance



> The other question is, can dpdk runs alongside with the linux network
> stack? I want to use dpdk in my special app but i still want to have ssh
> and apps working as expected without any modification.
>
Interface used by dpdk is not available, at least another interface
required for management/access &  other network apps



>
> Thanks in advance.
>

Re: [dpdk-users] To enable offloading DEV_TX_OFFLOAD_MULTI_SEGS per port and per queue

[Shyam Shrivastav]

The particular offload might be pure per port rather than per queue, anyway
you are enabling it at port level so no need to enable per queue.

Documentation is available at
http://doc.dpdk.org/guides/prog_guide/poll_mode_drv.html , some relevant
excerpt

The dev_info->[rt]x_queue_offload_capa returned from rte_eth_dev_info_get()
includes all per-queue offloading capabilities. The
dev_info->[rt]x_offload_capa returned from rte_eth_dev_info_get() includes
all pure per-port and per-queue offloading capabilities. Supported offloads
can be either per-port or per-queue.



On Mon, Apr 8, 2019 at 7:18 AM Anupama Laxmi 
wrote:

> I would like to enable per port offloading to set TX offloading for
> multiple segments using DEV_TX_OFFLOAD_MULTI_SEGS. UDP packets were getting
> dropped with error Bad UDP length > IP payload length as seen in the
> wireshark capture. This issue is seen after I upgraded to DPDK 18.08. Hence
> I would like to set the offload DEV_TX_OFFLOAD_MULTI_SEGS per port to allow
> segmenation of big packets.
>
> I am getting the below error when I try to set the above offload.
>
> Ethdev port_id=0 tx_queue_id=0, new added offloads 0x9f3e55 must be within
> pre-queue offload capabilities 0x0 in rte_eth_tx_queue_setup()
>
> Please let me know where I am going wrong and how do I set the offload
> DEV_TX_OFFLOAD_MULTI_SEGS correctly.
>
> static const struct rte_eth_txconf tx_conf = {
> .tx_thresh = {
> .pthresh = TX_PTHRESH,
> .hthresh = TX_HTHRESH,
> .wthresh = TX_WTHRESH,
> },
> .tx_free_thresh = 0,
> .tx_rs_thresh = 0,
> };
>
>
> static struct rte_eth_conf port_conf = {
> .rxmode = {
> .mq_mode = ETH_MQ_RX_RSS,
> .max_rx_pkt_len = JUMBO_FRAME_MAX_SIZE,
> .split_hdr_size = 0,
> .offloads = (DEV_RX_OFFLOAD_CHECKSUM |
>  DEV_RX_OFFLOAD_CRC_STRIP),
> },
> .rx_adv_conf = {
> .rss_conf = {
> .rss_key = NULL,
> .rss_hf = ETH_RSS_TCP| ETH_RSS_UDP |
>  ETH_RSS_TCP | ETH_RSS_SCTP,
> },
> },
> .txmode = {
> .mq_mode = ETH_MQ_TX_NONE,
> },
> };
>
>
> struct rte_eth_txconf *tx_conf;
> struct rte_eth_conf local_port_conf = port_conf;
> if(dev_info.tx_offload_capa & DEV_TX_OFFLOAD_MULTI_SEGS)
> {
>
>local_port_conf.txmode.offloads |= DEV_TX_OFFLOAD_MULTI_SEGS;
> }
> ret = rte_eth_dev_configure(port, nbqueue, nbqueue, _port_conf);
> rte_eth_dev_info_get(port, _info);
> tx_conf = _info.default_txconf;
> tx_conf->offloads = local_port_conf.txmode.offloads;
>
> ret = rte_eth_tx_queue_setup(port, queue, RTE_TEST_TX_DESC_DEFAULT,
> master_socket_id, _conf);
>

Re: [dpdk-users] [dpdk-dev] IPV4/IPV6 TCP/UDP Pseudo Header Checksum APIs

[Shyam Shrivastav]

Yes you are right, I misread, following code (ipv4 case) assumes no ip
options while calculating pseudo hdr length field

psd_hdr.len = rte_cpu_to_be_16(
(uint16_t)(rte_be_to_cpu_16(ipv4_hdr->total_length)
- sizeof(struct ipv4_hdr)));

should be

 psd_hdr.len = rte_cpu_to_be_16(
(uint16_t)(rte_be_to_cpu_16(ipv4_hdr->total_length)
- (ipv4_hdr->version_ihl & 0x0f)*4)));

On Sat, Oct 20, 2018 at 11:44 AM lidejun  wrote:

> I mean DPDK APIs do not exclude ipv4 options or ipv6 extension headers, it
> is bug?
>
>
>
> *发件人:* Shyam Shrivastav [mailto:shrivastav.sh...@gmail.com]
> *发送时间:* 2018年10月20日 13:23
> *收件人:* lidejun 
> *抄送:* users ; d...@dpdk.org; Lichunhe (Cloud Networking) <
> lichu...@huawei.com>; Wangliefeng 
> *主题:* Re: [dpdk-dev] IPV4/IPV6 TCP/UDP Pseudo Header Checksum APIs
>
>
>
> Realized my answer is confusing, I meant to say that code is correct as
> pseudo ipv4/ipv6 headers for the purpose of checksum calculations doesn't
> include options or extension headers, see udp wiki or corresponding rfcs
>
>
>
> https://en.wikipedia.org/wiki/User_Datagram_Protocol
>
>
>
> On Sat, Oct 20, 2018 at 10:42 AM Shyam Shrivastav <
> shrivastav.sh...@gmail.com> wrote:
>
> that is correct , pseudo header doesn't include ipv4 options or ipv6
> extension headers ..
>
>
>
> On Sat, Oct 20, 2018 at 9:02 AM lidejun  wrote:
>
> Has anybody used the following two APIs calculating ipv4 tcp/udp
> pseudo header checksum？
>
> 1.rte_ipv4_phdr_cksum
>
> 2.rte_ipv6_phdr_cksum
> The ipv4 version does not exclude ip options and ipv6 version does not
> exclude extersion headers.
>
>

Re: [dpdk-users] [dpdk-dev] IPV4/IPV6 TCP/UDP Pseudo Header Checksum APIs

[Shyam Shrivastav]

Realized my answer is confusing, I meant to say that code is correct as
pseudo ipv4/ipv6 headers for the purpose of checksum calculations doesn't
include options or extension headers, see udp wiki or corresponding rfcs

https://en.wikipedia.org/wiki/User_Datagram_Protocol

On Sat, Oct 20, 2018 at 10:42 AM Shyam Shrivastav <
shrivastav.sh...@gmail.com> wrote:

> that is correct , pseudo header doesn't include ipv4 options or ipv6
> extension headers ..
>
> On Sat, Oct 20, 2018 at 9:02 AM lidejun  wrote:
>
>> Has anybody used the following two APIs calculating ipv4 tcp/udp
>> pseudo header checksum？
>>
>> 1.rte_ipv4_phdr_cksum
>>
>> 2.rte_ipv6_phdr_cksum
>> The ipv4 version does not exclude ip options and ipv6 version does not
>> exclude extersion headers.
>>
>

Re: [dpdk-users] [dpdk-dev] IPV4/IPV6 TCP/UDP Pseudo Header Checksum APIs

[Shyam Shrivastav]

that is correct , pseudo header doesn't include ipv4 options or ipv6
extension headers ..

On Sat, Oct 20, 2018 at 9:02 AM lidejun  wrote:

> Has anybody used the following two APIs calculating ipv4 tcp/udp
> pseudo header checksum？
>
> 1.rte_ipv4_phdr_cksum
>
> 2.rte_ipv6_phdr_cksum
> The ipv4 version does not exclude ip options and ipv6 version does not
> exclude extersion headers.
>

Re: [dpdk-users] Calculating Packet Length

[Shyam Shrivastav]

We have to use sizeof(struct ether_hdr) , length set is wrong and 8 bytes
short

struct ether_hdr {
struct ether_addr d_addr; /**< Destination address. */
struct ether_addr s_addr; /**< Source address. */
uint16_t ether_type;  /**< Frame type. */
} __attribute__((__packed__));


On Sat, Sep 29, 2018 at 3:49 PM Michael Barker  wrote:

> Hi,
>
> I've new to DPDK and have been started by sending ARP packets.  I have a
> question around how to set the mbuf data_len and pkt_size.  I Initially did
> the following:
>
> struct rte_mbuf* arp_pkt = rte_pktmbuf_alloc(mbuf_pool);
> const size_t pkt_size = sizeof(struct ether_addr) + sizeof(struct
> arp_hdr);
>
> arp_pkt->data_len = pkt_size;
> arp_pkt->pkt_len = pkt_size;
>
> Which is based on ptpclient.c sample code.  However after setting all of
> the fields, the packet either doesn't get sent or has some of the data
> truncated from the end of the packet when viewed in Wireshark.  If I modify
> the size to be the following:
>
> const size_t pkt_size = sizeof(struct ether_addr) + sizeof(struct
> arp_hdr) + 8;
>
> It works as expected.  I'm wondering where the extra 8 bytes come from?  Is
> there a better way to calculate the packet length?
>
> Using dpdk 18.08, Linux - kernel 4.15.0-33.
>
> Mike.
>

Re: [dpdk-users] Sequence Number /More info on the Subject

[Shyam Shrivastav]

One obvious error that I can see in reply tcp segment is

th-⁠>recv_ack = htonl(client_send_seq + ntohs(iphdr-⁠>total_length));


You need to acknowledge just the tcp payload which is   { send seq +
iphdr-⁠>total_length - (IP header len) - (TCP header len) }







On Wed, Aug 15, 2018 at 7:47 PM, Konstantinos Schoinas 
wrote:

> Στις 2018-08-15 12:22, Konstantinos Schoinas έγραψε:
>
>>  Αρχικό μήνυμα 
>> Θέμα: Sequence Number
>> Ημερομηνία: 2018-08-15 12:21
>> Αποστολέας: Konstantinos Schoinas 
>> Παραλήπτης: users 
>>
>> Hello,
>>
>> I am building an application blocks TLS session if i find a sepcific
>> forbidden Server Name Indication.
>> According to RFC i must make a response with Fatal Error (2)
>> unrecognized name(112).
>>
>> When i receive the Client Hello and after i Extract the SNI and check
>> it against a black list i do process the client hello in order to
>> response to client and terminate the session.
>>
>> Although i am getting a lot of retransmit packets on wireshark so i
>> suppose i am doing something wrong.
>>
>> I think i mights have seq and ack number wrong or something.If anyone
>> could help i would appreciate.
>> Here is the process of the packet after i check for the forbidden SNI:
>>
>> uint32_t client_receive_ack = ntohl(th-⁠>recv_ack);
>> uint32_t client_send_seq = ntohl(th-⁠>sent_seq);
>>
>> th-⁠>sent_seq = th-⁠>recv_ack;
>> th-⁠>recv_ack = htonl(client_send_seq + ntohs(iphdr-⁠>total_length));
>>
>>
>> uint16_t l = ntohs(ssl-⁠>length)-⁠0x02;
>> uint16_t ip_l = ntohs(iphdr-⁠>total_length) -⁠ l;
>>
>> rte_pktmbuf_trim(m,l);
>> iphdr-⁠>total_length = htons(ip_l);
>> ssl-⁠>length = htons(2);
>>
>> alert = (struct Alert *)((uint8_t *)ssl + 5);
>>
>>
>> iphdr-⁠>src_addr = dst_ip;
>> iphdr-⁠>dst_addr = src_ip;
>> th-⁠>src_port = dst_port;
>> th-⁠>dst_port = src_port;
>> ssl-⁠>type = 21; //alert message
>> alert-⁠>type = 2; // fatal error
>> alert-⁠>description = 112; // Unrecognized name
>>
>> iphdr-⁠>hdr_checksum = 0;
>> th-⁠>cksum = 0;
>> iphdr-⁠>hdr_checksum = rte_ipv4_cksum(iphdr);
>>
>> th-⁠>cksum = rte_ipv4_udptcp_cksum(iphdr,th);
>>
>>
>>
>>
>> Thanks for your time
>>
>
>
>
>
> I wanted to give some more information on the subject.I am adding a
> picture of wireshark with the mail to give more info.The problem of the
> retransmitted packet is that it doesnt end the TLS session even though i am
> sending a fatal-error alert with dpdk.
>
> I believe that i do something wrong with the process of client hello so it
> doesnt have the right format in order to get recognized by the client and
> end the tls Session.
>
> If you see my code above i change the source ,dest ip and port the seq and
> ack value.In addition i am cutting from SSL Record the data that it had and
> i am adding the alert message according to RFC.
>
> Is there any field i must change according to dpdk?
>
>
>
>
>

Re: [dpdk-users] Security Block TLS

[Shyam Shrivastav]

As I understand

Step 1:  Generic implementation : TCP segments need to be filtered, if
destination port numbers are fixed/known ACL can include that else just
based on IP protocol field

http://dpdk.org/doc/guides/prog_guide/packet_classif_access_ctrl.html
http://dpdk.org/doc/guides/prog_guide/packet_framework.html
http://dpdk.org/doc/guides/sample_app_ug/ip_pipeline.html
http://dpdk.org/doc/guides/sample_app_ug/l3_forward_access_ctrl.html

However if your requirement is very specific as described, packets in burst
can be read from port (see following link for example) and packets with ip
protocol as TCP  filtered for further processing

http://dpdk.org/doc/guides/sample_app_ug/skeleton.html

 Step 2:  Generic pattern matching : Intel Hyperscan can be integrated with
dpdk and used, it works.   https://www.hyperscan.io/

Else you can just compare and filter by hardcoded string if use case is
very specific, that is just catching client hello message and then
filtering out based on certain field value.


On Wed, May 2, 2018 at 10:00 PM, Konstantinos Schoinas 
wrote:

> Hello,
>
> I wanna create a dpdk application that do something like this: Implement a
> simple blacklist with FQDN patterns. The dpdk app must extract the SNI from
> the Client Hello message of the TLS exchange. It will then check the SNI
> against the blacklist. If it matches, VNF shall block (drop packets) the
> TLS session, effectively disallowing the user from visiting the particular
> secure site.
>
> Can anyone give me any good information on what tools, libraries or sample
> applications I can use in order to create something like that?
>
> Thanks for your time,
>
> Konstantinos
>

Re: [dpdk-users] dpdk interfaces counters

[Shyam Shrivastav]

Yes rte_eth_stats_get() work by default, CONFIG_RTE_PORT_STATS_COLLECT
enables port stats in librte_port layer ..

On Wed, Aug 30, 2017 at 3:29 PM, Andriy Berestovskyy <a...@semihalf.com>
wrote:

> rte_eth_stats_get() works fine by default.
>
> Andriy
>
> On Wed, Aug 30, 2017 at 11:24 AM, Shyam Shrivastav
> <shrivastav.sh...@gmail.com> wrote:
> > Also port stats need to  be enabled in common config
> >
> > common_base:CONFIG_RTE_LIBRTE_ARK_DEBUG_STATS=n
> > common_base:CONFIG_RTE_LIBRTE_JOBSTATS=y
> > common_base:CONFIG_RTE_LIBRTE_LATENCY_STATS=y
> > common_base:CONFIG_RTE_SCHED_COLLECT_STATS=n
> > common_base:CONFIG_RTE_PORT_STATS_COLLECT=n
> > common_base:CONFIG_RTE_TABLE_STATS_COLLECT=n
> > common_base:CONFIG_RTE_PIPELINE_STATS_COLLECT=n
> > common_base:CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n
> >
> >
> > On Wed, Aug 30, 2017 at 2:49 PM, Andriy Berestovskyy <a...@semihalf.com>
> > wrote:
> >>
> >> Hey,
> >> Have a look at rte_eth_stats_get():
> >>
> >> http://dpdk.org/doc/api/rte__ethdev_8h.html#
> a97567472450b31ef53950fb2ef47298b
> >>
> >> Andriy
> >>
> >> On Wed, Aug 30, 2017 at 8:23 AM, Pragash Vijayaragavan <pxv3...@rit.edu
> >
> >> wrote:
> >> > Hi,
> >> >
> >> > I have 2 NICs connected to dpdk, I send traffic from 1 and receive on
> >> > the
> >> > other.
> >> >
> >> > Is there anyway how i can see the interface counters of these NICs to
> >> > check
> >> > whether my packets are received.
> >> >
> >> > Thanks,
> >> >
> >> > Pragash Vijayaragavan
> >> > Grad Student at Rochester Institute of Technology
> >> > email : pxv3...@rit.edu
> >> > ph : 585 764 4662
> >>
> >>
> >>
> >> --
> >> Andriy Berestovskyy
> >
> >
>
>
>
> --
> Andriy Berestovskyy
>

Re: [dpdk-users] dpdk interfaces counters

[Shyam Shrivastav]

Also port stats need to  be enabled in common config

common_base:CONFIG_RTE_LIBRTE_ARK_DEBUG_STATS=n
common_base:CONFIG_RTE_LIBRTE_JOBSTATS=y
common_base:CONFIG_RTE_LIBRTE_LATENCY_STATS=y
common_base:CONFIG_RTE_SCHED_COLLECT_STATS=n
common_base:CONFIG_RTE_PORT_STATS_COLLECT=n
common_base:CONFIG_RTE_TABLE_STATS_COLLECT=n
common_base:CONFIG_RTE_PIPELINE_STATS_COLLECT=n
common_base:CONFIG_RTE_TEST_PMD_RECORD_BURST_STATS=n


On Wed, Aug 30, 2017 at 2:49 PM, Andriy Berestovskyy 
wrote:

> Hey,
> Have a look at rte_eth_stats_get():
> http://dpdk.org/doc/api/rte__ethdev_8h.html#a97567472450b31ef53950fb2ef472
> 98b
>
> Andriy
>
> On Wed, Aug 30, 2017 at 8:23 AM, Pragash Vijayaragavan 
> wrote:
> > Hi,
> >
> > I have 2 NICs connected to dpdk, I send traffic from 1 and receive on the
> > other.
> >
> > Is there anyway how i can see the interface counters of these NICs to
> check
> > whether my packets are received.
> >
> > Thanks,
> >
> > Pragash Vijayaragavan
> > Grad Student at Rochester Institute of Technology
> > email : pxv3...@rit.edu
> > ph : 585 764 4662
>
>
>
> --
> Andriy Berestovskyy
>

Re: [dpdk-users] Strange packet loss with multi-frame payloads

[Shyam Shrivastav]

Yes your RSS configuration is not an issue ..

On Tue, Jul 18, 2017 at 4:36 PM, Harold Demure <harold.demur...@gmail.com>
wrote:

> Hello again,
>   At the bottom of this email you find my rte_eth_conf configuration,
> which includes RSS.
> For my NIC, documentation says RSS can only be used taking into account
> also the transport layer [1].
> For a given client/server pair, all the packets with the same src/dst port
> are received by the same core.
> So to ensure that all the fragments are received by the same core, I keep
> fixed the src-dst port.
>
> Indeed, this works just fine with smaller payloads (even multi-frame), and
> also the clients always get multi-frame replies, because an individual
> logical reply has all its segments delivered to the same client thread.
>
> Thank you again for your feedback.
> Regards,
>   Harold
>
> =
>
> [1] http://dpdk.org/doc/guides/nics/mlx4.html
>
> static struct rte_eth_conf port_conf = {
> .rxmode = {
> .mq_mode= ETH_MQ_RX_RSS,
> .split_hdr_size = 0,
> .header_split   = 0, /**< Header Split disabled */
> .hw_ip_checksum = 0, /**< IP checksum offload enabled */
> .hw_vlan_filter = 0, /**< VLAN filtering disabled */
> .jumbo_frame= 0, /**< Jumbo Frame Support disabled */
> .hw_strip_crc   = 0, /**< CRC stripped by hardware */
> .max_rx_pkt_len =  ETHER_MAX_LEN,
> .enable_scatter = 1
> },
> .rx_adv_conf = {
> .rss_conf = {
> .rss_key = NULL,
> .rss_hf = ETH_RSS_IP | ETH_RSS_UDP,
> },
> },
> .txmode = {
> .mq_mode = ETH_MQ_TX_NONE,
> },
> };
>
>
> 2017-07-18 12:07 GMT+02:00 Shyam Shrivastav <shrivastav.sh...@gmail.com>:
>
>> Hi Harold
>> I meant optimal performance w.r.t packets per second. If there is no loss
>> without app fragmentation at target pps with say 8 RX queues, and same
>> results in missing packets with app fragmentation then the issue might me
>> somewhere else. What is RSS configuration, you should not take transport
>> headers into account ETH_RSS_IPV4 is safe otherwise different app fragments
>> of same packet can go to different RX queues.
>>
>> On Tue, Jul 18, 2017 at 3:06 PM, Harold Demure <harold.demur...@gmail.com
>> > wrote:
>>
>>> Hello Shyam,
>>>Thank you for your suggestion. I will try what you say. However, this
>>> problem arises only with specific workloads. For example, if the clients
>>> only send requests of 1 frame, everything runs smoothly even with 16 active
>>> queues. My problem arises only with bigger payloads and multiple queues.
>>> Shouldn't this suggest that the problem is not "simply" that my NIC drops
>>> packets with > X active queues?
>>>
>>> Regards,
>>>   Harold
>>>
>>> 2017-07-18 7:50 GMT+02:00 Shyam Shrivastav <shrivastav.sh...@gmail.com>:
>>>
>>>> As I understand the problem disappears with 1 RX queue on server. You
>>>> can reduce number of queues on server from 8 and arrive at an optimal value
>>>> without packet loss.
>>>> For intel 82599 NIC packet loss is experienced with more than 4 RX
>>>> queues, this was reported in dpdk dev or user mailing list, read in
>>>> archives sometime back while looking for similar information with 82599.
>>>>
>>>> On Tue, Jul 18, 2017 at 4:54 AM, Harold Demure <
>>>> harold.demur...@gmail.com> wrote:
>>>>
>>>>> Hello again,
>>>>>   I tried to convert my statically defined buffers into buffers
>>>>> allocated
>>>>> through rte_malloc (as discussed in the previous email, see quoted
>>>>> text).
>>>>> Unfortunately, the problem is still there :(
>>>>> Regards,
>>>>>   Harold
>>>>>
>>>>>
>>>>>
>>>>> >
>>>>> > 2. How do you know you have the packet loss?
>>>>> >
>>>>> >
>>>>> > *I know it because some fragmented packets never get reassembled
>>>>> fully. If
>>>>> > I print the packets seen by the server I see something like
>>>>> "PCKT_ID 10
>>>>> > FRAG 250, PCKT_ID 10 FRAG 252". And FRAG 251 is never printed.*
>>>>> >
>>&

Re: [dpdk-users] Strange packet loss with multi-frame payloads

[Shyam Shrivastav]

Hi Harold
I meant optimal performance w.r.t packets per second. If there is no loss
without app fragmentation at target pps with say 8 RX queues, and same
results in missing packets with app fragmentation then the issue might me
somewhere else. What is RSS configuration, you should not take transport
headers into account ETH_RSS_IPV4 is safe otherwise different app fragments
of same packet can go to different RX queues.

On Tue, Jul 18, 2017 at 3:06 PM, Harold Demure <harold.demur...@gmail.com>
wrote:

> Hello Shyam,
>Thank you for your suggestion. I will try what you say. However, this
> problem arises only with specific workloads. For example, if the clients
> only send requests of 1 frame, everything runs smoothly even with 16 active
> queues. My problem arises only with bigger payloads and multiple queues.
> Shouldn't this suggest that the problem is not "simply" that my NIC drops
> packets with > X active queues?
>
> Regards,
>   Harold
>
> 2017-07-18 7:50 GMT+02:00 Shyam Shrivastav <shrivastav.sh...@gmail.com>:
>
>> As I understand the problem disappears with 1 RX queue on server. You can
>> reduce number of queues on server from 8 and arrive at an optimal value
>> without packet loss.
>> For intel 82599 NIC packet loss is experienced with more than 4 RX
>> queues, this was reported in dpdk dev or user mailing list, read in
>> archives sometime back while looking for similar information with 82599.
>>
>> On Tue, Jul 18, 2017 at 4:54 AM, Harold Demure <harold.demur...@gmail.com
>> > wrote:
>>
>>> Hello again,
>>>   I tried to convert my statically defined buffers into buffers allocated
>>> through rte_malloc (as discussed in the previous email, see quoted text).
>>> Unfortunately, the problem is still there :(
>>> Regards,
>>>   Harold
>>>
>>>
>>>
>>> >
>>> > 2. How do you know you have the packet loss?
>>> >
>>> >
>>> > *I know it because some fragmented packets never get reassembled
>>> fully. If
>>> > I print the packets seen by the server I see something like  "PCKT_ID
>>> 10
>>> > FRAG 250, PCKT_ID 10 FRAG 252". And FRAG 251 is never printed.*
>>> >
>>> > *Actually, something strange that happens sometimes is that a core
>>> > receives fragments of two packets and, say, receives   frag 1 of
>>> packet X,
>>> > frag 2 of packet Y, frag 3 of packet X, frag 4 of packet Y.*
>>> > *Or that, after "losing" a fragment for packet X, I only see printed
>>> > fragments with EVEN frag_id for that packet X. At least for a while.*
>>> >
>>> > *This led me also to consider a bug in my implementation (I don't
>>> > experience this problem if I run with a SINGLE client thread). However,
>>> > with smaller payloads, even fragmented, everything runs smoothly.*
>>> > *If you have any suggestions for tests to run to spot a possible bug
>>> in my
>>> > implementation, It'd be more than welcome!*
>>> >
>>> > *MORE ON THIS: the buffers in which I store the packets taken from RX
>>> are
>>> > statically defined arrays, like struct rte_mbuf*  temp_mbuf[SIZE].
>>> SIZE
>>> > can be pretty high (say, 10K entries), and there are 3 of those arrays
>>> per
>>> > core. Can it be that, somehow, they mess up the memory layout (e.g.,
>>> they
>>> > intersect)?*
>>> >
>>>
>>
>>
>

Re: [dpdk-users] Strange packet loss with multi-frame payloads

[Shyam Shrivastav]

As I understand the problem disappears with 1 RX queue on server. You can
reduce number of queues on server from 8 and arrive at an optimal value
without packet loss.
For intel 82599 NIC packet loss is experienced with more than 4 RX queues,
this was reported in dpdk dev or user mailing list, read in archives
sometime back while looking for similar information with 82599.

On Tue, Jul 18, 2017 at 4:54 AM, Harold Demure 
wrote:

> Hello again,
>   I tried to convert my statically defined buffers into buffers allocated
> through rte_malloc (as discussed in the previous email, see quoted text).
> Unfortunately, the problem is still there :(
> Regards,
>   Harold
>
>
>
> >
> > 2. How do you know you have the packet loss?
> >
> >
> > *I know it because some fragmented packets never get reassembled fully.
> If
> > I print the packets seen by the server I see something like  "PCKT_ID 10
> > FRAG 250, PCKT_ID 10 FRAG 252". And FRAG 251 is never printed.*
> >
> > *Actually, something strange that happens sometimes is that a core
> > receives fragments of two packets and, say, receives   frag 1 of packet
> X,
> > frag 2 of packet Y, frag 3 of packet X, frag 4 of packet Y.*
> > *Or that, after "losing" a fragment for packet X, I only see printed
> > fragments with EVEN frag_id for that packet X. At least for a while.*
> >
> > *This led me also to consider a bug in my implementation (I don't
> > experience this problem if I run with a SINGLE client thread). However,
> > with smaller payloads, even fragmented, everything runs smoothly.*
> > *If you have any suggestions for tests to run to spot a possible bug in
> my
> > implementation, It'd be more than welcome!*
> >
> > *MORE ON THIS: the buffers in which I store the packets taken from RX are
> > statically defined arrays, like struct rte_mbuf*  temp_mbuf[SIZE].  SIZE
> > can be pretty high (say, 10K entries), and there are 3 of those arrays
> per
> > core. Can it be that, somehow, they mess up the memory layout (e.g., they
> > intersect)?*
> >
>

Re: [dpdk-users] Question about range type of DPDK ACL

[Shyam Shrivastav]

Yes you are right , the IPv4 conversion keeps the host byte and ip address
in packet mbuf would appear other way round for matching.
I got confused because firewall parser code reads the dotted decimal user
input as big endian, that's why rte_be_to_cpu32 is required.
Hope some help comes your way, you can also try posting in dpdk dev
d...@dpdk.org

On Thu, Jun 22, 2017 at 12:57 PM, Doohwan Lee <let...@gmail.com> wrote:

> I really appreciate your help. but I think there's some misunderstanding.
> I also know that DPDK ACL rule expects host order.
>
> IPv4(1,2,3,4) means 0x01020304 and it is little endian(host order) again.
> and the IP address 1.2.3.4 in packet data on memory is 0x04030201 (big
> endian).
> So, I think I didn't have any mistake for using DPDK ACL library.
>
>
>
> 2017-06-22 16:12 GMT+09:00 Shyam Shrivastav <shrivastav.sh...@gmail.com>:
>
>> No it is not as dotted decimal representation is in big endian that is as
>> they appear in packet, but acl library expects addition in host byte order.
>> I would suggest to try the change, in firewall also we are converting user
>> input in dotted decimal to integer then to host byte order .., anyway it is
>> your choice
>>
>> On Thu, Jun 22, 2017 at 12:28 PM, Doohwan Lee <let...@gmail.com> wrote:
>>
>>> IPv4(1,2,3,4) means 0x01020304, and it is already host order (little
>>> endian).
>>> It need not to be converted using rte_be_to_cpu32() for setting rule.
>>>
>>>
>>>
>>> 2017-06-22 15:27 GMT+09:00 Shyam Shrivastav <shrivastav.sh...@gmail.com>
>>> :
>>>
>>>>
>>>> Yes Doohwan,  it is there in rte_ip.h just saw. So this conversion
>>>> leaves the address in big endian format. Theoretically, we are supposed to
>>>> add the acl fields in host order, if you see pipeline code even for ip
>>>> address with mask, following conversion is being done line 1096
>>>> examples/ip_pipeline/pipeline-firewall.c
>>>>
>>>> key.type = PIPELINE_FIREWALL_IPV4_5TUPLE;
>>>> key.key.ipv4_5tuple.src_ip = rte_be_to_cpu_32(sipaddr.s_addr);
>>>> key.key.ipv4_5tuple.src_ip_mask = sipdepth;
>>>> key.key.ipv4_5tuple.dst_ip = rte_be_to_cpu_32(dipaddr.s_addr);
>>>>
>>>> I would suggest this in your code
>>>>
>>>> rule->field[2].value.u32 = rte_be_to_cpu_32(IPv4(1,2,3,4));
>>>> rule->filed[2].mask_range.u32 = rte_be_to_cpu_32(IPv4(1,10,10,10));
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jun 22, 2017 at 11:28 AM, Doohwan Lee <let...@gmail.com> wrote:
>>>>
>>>>> Ok. The code to set rule for IPv4 address is like below.
>>>>>
>>>>> 
>>>>> #define IPv4(a,b,c,d) ((uint32_t)(((a) & 0xff) << 24) | \
>>>>>(((b) & 0xff) << 16) | \
>>>>>(((c) & 0xff) << 8)  | \
>>>>>((d) & 0xff))
>>>>>
>>>>> ...
>>>>> rule->field[2].value.u32 = IPv4(1,2,3,4);
>>>>> rule->filed[2].mask_range.u32 = IPv4(1,10,10,10);
>>>>> ...
>>>>> -
>>>>>
>>>>> The macro IPv4() is from the DPDK (rte_ip.h)
>>>>> The matching data is from the packet. so it is network order. (big
>>>>> endian)
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jun 22, 2017 at 1:26 PM, Shyam Shrivastav <
>>>>> shrivastav.sh...@gmail.com> wrote:
>>>>>
>>>>>> Yes if these are the results then might be some issue, but can not be
>>>>>> sure unless do this myself, have been using ACL library but not this case
>>>>>> till now.
>>>>>> Can you share code fragment converting dotted decimal to integer if
>>>>>> possible ..
>>>>>>
>>>>>> On Thu, Jun 22, 2017 at 7:57 AM, Doohwan Lee <let...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Thank you Shyam.
>>>>>>> Let me explain my situation in detail.
>>>>>>> All the cases described below use RTE_ACL_FIELD_TYPE_RANGE type.
>>>>>>>
>>>>>>> 

Re: [dpdk-users] Question about range type of DPDK ACL

[Shyam Shrivastav]

No it is not as dotted decimal representation is in big endian that is as
they appear in packet, but acl library expects addition in host byte order.
I would suggest to try the change, in firewall also we are converting user
input in dotted decimal to integer then to host byte order .., anyway it is
your choice

On Thu, Jun 22, 2017 at 12:28 PM, Doohwan Lee <let...@gmail.com> wrote:

> IPv4(1,2,3,4) means 0x01020304, and it is already host order (little
> endian).
> It need not to be converted using rte_be_to_cpu32() for setting rule.
>
>
>
> 2017-06-22 15:27 GMT+09:00 Shyam Shrivastav <shrivastav.sh...@gmail.com>:
>
>>
>> Yes Doohwan,  it is there in rte_ip.h just saw. So this conversion leaves
>> the address in big endian format. Theoretically, we are supposed to add the
>> acl fields in host order, if you see pipeline code even for ip address with
>> mask, following conversion is being done line 1096
>> examples/ip_pipeline/pipeline-firewall.c
>>
>> key.type = PIPELINE_FIREWALL_IPV4_5TUPLE;
>> key.key.ipv4_5tuple.src_ip = rte_be_to_cpu_32(sipaddr.s_addr);
>> key.key.ipv4_5tuple.src_ip_mask = sipdepth;
>> key.key.ipv4_5tuple.dst_ip = rte_be_to_cpu_32(dipaddr.s_addr);
>>
>> I would suggest this in your code
>>
>> rule->field[2].value.u32 = rte_be_to_cpu_32(IPv4(1,2,3,4));
>> rule->filed[2].mask_range.u32 = rte_be_to_cpu_32(IPv4(1,10,10,10));
>>
>>
>>
>>
>>
>>
>> On Thu, Jun 22, 2017 at 11:28 AM, Doohwan Lee <let...@gmail.com> wrote:
>>
>>> Ok. The code to set rule for IPv4 address is like below.
>>>
>>> 
>>> #define IPv4(a,b,c,d) ((uint32_t)(((a) & 0xff) << 24) | \
>>>(((b) & 0xff) << 16) | \
>>>(((c) & 0xff) << 8)  | \
>>>((d) & 0xff))
>>>
>>> ...
>>> rule->field[2].value.u32 = IPv4(1,2,3,4);
>>> rule->filed[2].mask_range.u32 = IPv4(1,10,10,10);
>>> ...
>>> -
>>>
>>> The macro IPv4() is from the DPDK (rte_ip.h)
>>> The matching data is from the packet. so it is network order. (big
>>> endian)
>>>
>>>
>>>
>>> On Thu, Jun 22, 2017 at 1:26 PM, Shyam Shrivastav <
>>> shrivastav.sh...@gmail.com> wrote:
>>>
>>>> Yes if these are the results then might be some issue, but can not be
>>>> sure unless do this myself, have been using ACL library but not this case
>>>> till now.
>>>> Can you share code fragment converting dotted decimal to integer if
>>>> possible ..
>>>>
>>>> On Thu, Jun 22, 2017 at 7:57 AM, Doohwan Lee <let...@gmail.com> wrote:
>>>>
>>>>> Thank you Shyam.
>>>>> Let me explain my situation in detail.
>>>>> All the cases described below use RTE_ACL_FIELD_TYPE_RANGE type.
>>>>>
>>>>> ---
>>>>> Case 1.
>>>>> rule: 1.2.3.4 ~ 1.2.3.4
>>>>> packet: 1.2.3.4
>>>>> result: match (correct)
>>>>>
>>>>> Case 2.
>>>>> rule: 1.2.3.4 ~ 1.10.10.10
>>>>> packet: 1.2.10.5
>>>>> result: match (correct)
>>>>>
>>>>> Case 3
>>>>> rule: 1.2.3.4 ~ 1.10.10.10
>>>>> packet: 1.10.10.11
>>>>> result: not match (correct)
>>>>>
>>>>> Case 4
>>>>> rule: 1.2.3.4 ~ 1.10.10.10
>>>>> packet: 1.2.3.10
>>>>> result: match (correct)
>>>>>
>>>>> Case 5:
>>>>> rule: 1.2.3.4~1.10.10.10
>>>>> packet: 1.2.10.11
>>>>> result: not match (incorrect)
>>>>>
>>>>> Case 6:
>>>>> rule: 1.2.3.4~1.10.10.10
>>>>> packet: 1.2.10.3
>>>>> result: not match (incorrect)
>>>>> ---
>>>>>
>>>>>
>>>>> Considering case 1~4, It shows expected results and there is no
>>>>> problem with byte ordering.
>>>>> But, in case 5~6, the result should be 'match' but it was not.
>>>>> This is why I doubt DPDK ACL library doesn't support 32-bit range
>>>>> matching.
>>>>>
>>

Re: [dpdk-users] Question about range type of DPDK ACL

[Shyam Shrivastav]

Yes if these are the results then might be some issue, but can not be sure
unless do this myself, have been using ACL library but not this case till
now.
Can you share code fragment converting dotted decimal to integer if
possible ..

On Thu, Jun 22, 2017 at 7:57 AM, Doohwan Lee <let...@gmail.com> wrote:

> Thank you Shyam.
> Let me explain my situation in detail.
> All the cases described below use RTE_ACL_FIELD_TYPE_RANGE type.
>
> ---
> Case 1.
> rule: 1.2.3.4 ~ 1.2.3.4
> packet: 1.2.3.4
> result: match (correct)
>
> Case 2.
> rule: 1.2.3.4 ~ 1.10.10.10
> packet: 1.2.10.5
> result: match (correct)
>
> Case 3
> rule: 1.2.3.4 ~ 1.10.10.10
> packet: 1.10.10.11
> result: not match (correct)
>
> Case 4
> rule: 1.2.3.4 ~ 1.10.10.10
> packet: 1.2.3.10
> result: match (correct)
>
> Case 5:
> rule: 1.2.3.4~1.10.10.10
> packet: 1.2.10.11
> result: not match (incorrect)
>
> Case 6:
> rule: 1.2.3.4~1.10.10.10
> packet: 1.2.10.3
> result: not match (incorrect)
> ---
>
>
> Considering case 1~4, It shows expected results and there is no problem
> with byte ordering.
> But, in case 5~6, the result should be 'match' but it was not.
> This is why I doubt DPDK ACL library doesn't support 32-bit range matching.
>
>
> On Wed, Jun 21, 2017 at 9:09 PM, Shyam Shrivastav <
> shrivastav.sh...@gmail.com> wrote:
>
>> I haven't used range type with 32 bit integers yet ...
>> Just some theory in case if you haven't already taken into account,  if
>> little-endian host 10.10.10.30 actually means 0x1e0a0a0a for acl match,
>> dotted decimal is in big endian so when in little endian host you need to
>> add it other way round as integers for matching. This means if you add
>> range 0x0a0a0a0a to 0x1e1e1e1e should match 10.10.10.30,  this is my
>> understanding theoretically ..
>>
>> On Wed, Jun 21, 2017 at 4:54 PM, Doohwan Lee <let...@gmail.com> wrote:
>>
>>> Yes. you are right. I also already knew that 32bit match with mask type
>>> works well.
>>> My point is 32bit match with 'range type' doesn't work in some case.
>>>
>>>
>>> On Wed, Jun 21, 2017 at 6:46 PM, Anupam Kapoor <anupam.kap...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> On Wed, Jun 21, 2017 at 11:36 AM, Doohwan Lee <let...@gmail.com> wrote:
>>>>
>>>>> DPDK ACL library uses multi-bit trie with 8-bit stride.
>>>>> I guess that implementation of the trie doesn't support 32bit range
>>>>> matching.
>>>>>
>>>>
>>>> ​well, you _can_ have address wildcard matches e.g. an address+mask
>>>> combination of 1.2.3.0/24 would match all addresses 1.2.3.[0..255]
>>>>
>>>> ​--
>>>> kind regards
>>>> anupam​
>>>>
>>>> In the beginning was the lambda, and the lambda was with Emacs, and
>>>> Emacs was the lambda.
>>>>
>>>
>>>
>>
>

Re: [dpdk-users] Question about range type of DPDK ACL

[Shyam Shrivastav]

I haven't used range type with 32 bit integers yet ...
Just some theory in case if you haven't already taken into account,  if
little-endian host 10.10.10.30 actually means 0x1e0a0a0a for acl match,
dotted decimal is in big endian so when in little endian host you need to
add it other way round as integers for matching. This means if you add
range 0x0a0a0a0a to 0x1e1e1e1e should match 10.10.10.30,  this is my
understanding theoretically ..

On Wed, Jun 21, 2017 at 4:54 PM, Doohwan Lee  wrote:

> Yes. you are right. I also already knew that 32bit match with mask type
> works well.
> My point is 32bit match with 'range type' doesn't work in some case.
>
>
> On Wed, Jun 21, 2017 at 6:46 PM, Anupam Kapoor 
> wrote:
>
>>
>> On Wed, Jun 21, 2017 at 11:36 AM, Doohwan Lee  wrote:
>>
>>> DPDK ACL library uses multi-bit trie with 8-bit stride.
>>> I guess that implementation of the trie doesn't support 32bit range
>>> matching.
>>>
>>
>> ​well, you _can_ have address wildcard matches e.g. an address+mask
>> combination of 1.2.3.0/24 would match all addresses 1.2.3.[0..255]
>>
>> ​--
>> kind regards
>> anupam​
>>
>> In the beginning was the lambda, and the lambda was with Emacs, and Emacs
>> was the lambda.
>>
>
>

Re: [dpdk-users] Question about range type of DPDK ACL

[Shyam Shrivastav]

Yes it can be but generally not used. Check dotted decimal IP address to
integer conversion, ACL library expects host byte order while adding acl
rules and network byte order while matching ..

FROM ADD

rules: Array of rules to add to the ACL context. Note that all fields
in rte_acl_rule structures are expected to be in host byte order. Each rule
expected to be in the same format and not exceed size specified at ACL
context creation time.

FROM CLASSIFY

data  : Array of pointers to input data buffers to perform search. Note
that all fields in input data buffers supposed to be in network byte order
(MSB).


On Wed, Jun 21, 2017 at 6:20 AM, 이두환 <let...@gmail.com> wrote:

> IPv4 address can be just 4byte integer value.
> 10.10.10.10 means 0x0a0a0a0a and 20.20.20.20 means 0x14141414
> 10.10.10.30 is 0x0a0a0a1e and it is greater than 0x0a0a0a0a and less then
> 0x14141414.
> So, I think it should be matched but the result was not.
> Did I miss something?
>
> On Tue, Jun 20, 2017 at 5:58 PM, Shyam Shrivastav <
> shrivastav.sh...@gmail.com> wrote:
>
>> RTE_ACL_FIELD_TYPE_RANGE is for linear integer range like port numbers
>> For ip addresses RTE_ACL_FIELD_TYPE_MASK should be used.
>>
>> On Tue, Jun 20, 2017 at 1:57 PM, 이두환 <let...@gmail.com> wrote:
>>
>>> Hello everyone.
>>>
>>> I want to implement some feature like ACL using DPDK ACL library.
>>> so, I defined rule like below.
>>>
>>> struct acl_match_component
>>> {
>>> uint8_t protocol;
>>> uint32_t sip;
>>> uint32_t dip;
>>> uint16_t sport;
>>> uint16_t dport;
>>> uint16_t in_if;
>>> uint16_t out_if;
>>> }
>>>
>>>
>>> struct rte_acl_field_def ipv4_defs[7] = {
>>> {
>>> .type = RTE_ACL_FIELD_TYPE_RANGE,
>>> .size = sizeof(uint8_t),
>>> .field_index = 0,
>>> .input_index = 0,
>>> .offset = 0
>>> },
>>> {
>>> .type = RTE_ACL_FIELD_TYPE_RANGE,
>>> .size = sizeof(uint32_t),
>>> .field_index = 1,
>>> .input_index = 1,
>>> .offset = offsetof(struct acl_match_component, sip)
>>> },
>>> {
>>> .type = RTE_ACL_FIELD_TYPE_RANGE,
>>> .size = sizeof(uint32_t),
>>> .field_index = 2,
>>> .input_index = 2,
>>> .offset = offsetof(struct acl_match_component, dip)
>>> },
>>> {
>>> .type = RTE_ACL_FIELD_TYPE_RANGE,
>>> .size = sizeof(uint16_t),
>>> .field_index = 3,
>>> .input_index = 3,
>>> .offset = offsetof(struct acl_match_component, sport)
>>> },
>>> {
>>> .type = RTE_ACL_FIELD_TYPE_RANGE,
>>> .size = sizeof(uint16_t),
>>> .field_index = 4,
>>> .input_index = 3,
>>> .offset = offsetof(struct acl_match_component, dport)
>>> },
>>> {
>>> .type = RTE_ACL_FIELD_TYPE_RANGE,
>>> .size = sizeof(uint16_t),
>>> .field_index = 5,
>>> .input_index = 4,
>>> .offset = offsetof(struct acl_match_component, in_if)
>>> },
>>> {
>>> .type = RTE_ACL_FIELD_TYPE_RANGE,
>>> .size = sizeof(uint16_t),
>>> .field_index = 6,
>>> .input_index = 4,
>>> .offset = offsetof(struct acl_match_component, out_if)
>>> },
>>> };
>>>
>>> I defined 32bit IPv4 address filed as RTE_ACL_FIELD_TYPE_RANGE type.
>>> and I set rte_acl_field for IP field like below.
>>>
>>> value.u32 = IPv4(10,10,10,10);
>>> mask_range.u32 = IPv4(20,20,20,20);
>>>
>>> In this case, I think IP 10.10.10.15 and 10.10.10.30 should be matched.
>>> but result was IP 10.10.10.15 was matched and 10.10.10.30 was not
>>> matched.
>>>
>>> I am using DPDK 16.04 and there was no example in the DPDK source using
>>> 32bit field as range type.
>>> Range type with 16bit field (ex. port number) works well.
>>> And, DPDK 17.05 has no meaningful changes on ACL library compare to DPDK
>>> 16.04
>>>
>>> Do you have any idea about this?
>>>
>>> Thank you.
>>>
>>
>>
>

Re: [dpdk-users] Question about range type of DPDK ACL

[Shyam Shrivastav]

RTE_ACL_FIELD_TYPE_RANGE is for linear integer range like port numbers
For ip addresses RTE_ACL_FIELD_TYPE_MASK should be used.

On Tue, Jun 20, 2017 at 1:57 PM, 이두환  wrote:

> Hello everyone.
>
> I want to implement some feature like ACL using DPDK ACL library.
> so, I defined rule like below.
>
> struct acl_match_component
> {
> uint8_t protocol;
> uint32_t sip;
> uint32_t dip;
> uint16_t sport;
> uint16_t dport;
> uint16_t in_if;
> uint16_t out_if;
> }
>
>
> struct rte_acl_field_def ipv4_defs[7] = {
> {
> .type = RTE_ACL_FIELD_TYPE_RANGE,
> .size = sizeof(uint8_t),
> .field_index = 0,
> .input_index = 0,
> .offset = 0
> },
> {
> .type = RTE_ACL_FIELD_TYPE_RANGE,
> .size = sizeof(uint32_t),
> .field_index = 1,
> .input_index = 1,
> .offset = offsetof(struct acl_match_component, sip)
> },
> {
> .type = RTE_ACL_FIELD_TYPE_RANGE,
> .size = sizeof(uint32_t),
> .field_index = 2,
> .input_index = 2,
> .offset = offsetof(struct acl_match_component, dip)
> },
> {
> .type = RTE_ACL_FIELD_TYPE_RANGE,
> .size = sizeof(uint16_t),
> .field_index = 3,
> .input_index = 3,
> .offset = offsetof(struct acl_match_component, sport)
> },
> {
> .type = RTE_ACL_FIELD_TYPE_RANGE,
> .size = sizeof(uint16_t),
> .field_index = 4,
> .input_index = 3,
> .offset = offsetof(struct acl_match_component, dport)
> },
> {
> .type = RTE_ACL_FIELD_TYPE_RANGE,
> .size = sizeof(uint16_t),
> .field_index = 5,
> .input_index = 4,
> .offset = offsetof(struct acl_match_component, in_if)
> },
> {
> .type = RTE_ACL_FIELD_TYPE_RANGE,
> .size = sizeof(uint16_t),
> .field_index = 6,
> .input_index = 4,
> .offset = offsetof(struct acl_match_component, out_if)
> },
> };
>
> I defined 32bit IPv4 address filed as RTE_ACL_FIELD_TYPE_RANGE type.
> and I set rte_acl_field for IP field like below.
>
> value.u32 = IPv4(10,10,10,10);
> mask_range.u32 = IPv4(20,20,20,20);
>
> In this case, I think IP 10.10.10.15 and 10.10.10.30 should be matched.
> but result was IP 10.10.10.15 was matched and 10.10.10.30 was not matched.
>
> I am using DPDK 16.04 and there was no example in the DPDK source using
> 32bit field as range type.
> Range type with 16bit field (ex. port number) works well.
> And, DPDK 17.05 has no meaningful changes on ACL library compare to DPDK
> 16.04
>
> Do you have any idea about this?
>
> Thank you.
>

Re: [dpdk-users] [dpdk-dev] how to build 'example' folder in dpdk-2.2.0?

[Shyam Shrivastav]

For linux

http://dpdk.org/doc/guides/linux_gsg/index.html
http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html
http://dpdk.org/doc/guides/linux_gsg/build_sample_apps.html

On Fri, Jun 9, 2017 at 8:31 AM, Sam  wrote:

> hi all,
>
> I want to build example(DPDK_HOME/example/*) in dpdk, and to have a look at
> vhost demo. But I can't find guide in dpdk home page or document.
>
> So is there some document to tell me HOWTO?
>

Re: [dpdk-users] pktgen - IP address randomness

[Shyam Shrivastav]

Sometime back I used lua in moongen to continuously generate ip:tcp packets
with random ip src and random tcp src/dst ports. Here is the corresponding
lua script fragment, don't know how much useful it can be with pktgen as I
have not looked at or used pktgen till now but just in case ...


x1 = math.random(1,254);
x2 = math.random(1,254);
x3 = math.random(1,254);
x4 = math.random(1,254);
p1 = math.random(1025,65534);
p2 = math.random(1025,65534);
pkt.ip.src:set(x1*256*256*256 + x2*256*256 + x3*256
+ x4)
pkt.tcp:setSrcPort(p1);
pkt.tcp:setDstPort(p2);




On Tue, May 23, 2017 at 5:01 AM, Chris Hall 
wrote:

> Hello,
>
> pktgen-3.2.4
>
> I Looking to get as much randomness out of src ip’s as possible. Using
> this config in lua…
>
> pktgen.src_ip('0', 'start',"0.0.0.1");
> pktgen.src_ip('0', 'min', "0.0.0.1");
> pktgen.src_ip('0', 'max', "255.255.255.254");
> pktgen.src_ip('0', 'inc', "1.1.1.1");
>
> running a packet capture of 5Million packets on the receiving host,
> parsing the pcap file, based on source ip, seems I can only get about 32769
> uniq ip's, (each connected about 150 times).
>
> As a comparison I used hping3 with --rand-source option (5million packets)
> I can get about 4942744 uniq ip’s.
>
> Is there a configure option(s) somewhere that could be tuned for more
> randomness or is the above parms just wrong ?
>
> Thanks much.
>
>   *   Chris
>
>
>
>

Re: [dpdk-users] [dpdk-dev] Defining multiple actions based on a field value for the same table lookup in ip_pipeline application

[Shyam Shrivastav]

That can be done in the same miss function as I understand, if (condition1)
{} else {}

On Fri, May 19, 2017 at 10:53 AM, Nidhia Varghese <
nidhiavarghes...@gmail.com> wrote:

> Thanks for your reply Shyam.
> Yes, I went through it. But my doubt is whether it is possible to define
> two different miss actions based on some decision criteria(input port in my
> case).
> Miss ->Case 1: Add entry to table if portid = 1
> ->Case 2: Drop if portid = 2
>
> On Thu, May 18, 2017 at 7:34 PM, Shyam Shrivastav <
> shrivastav.sh...@gmail.com> wrote:
>
>> For each table a lookup hit and miss function can be registered, have a
>> look at
>> rte_pipeline_run(struct rte_pipeline *p) for the semantics
>>
>
> Thanks,
> Nidhia Varghese
>

Re: [dpdk-users] [dpdk-dev] Defining multiple actions based on a field value for the same table lookup in ip_pipeline application

[Shyam Shrivastav]

For each table a lookup hit and miss function can be registered, have a
look at
rte_pipeline_run(struct rte_pipeline *p) for the semantics

On Thu, May 18, 2017 at 5:53 PM, Nidhia Varghese  wrote:

> Hi all,
>
> I am trying to design a pipeline where the table lookup has to do the
> actions as follows:
>
> Lookup hit -> FWD to port
> Lookup miss -> add a table entry if incoming port was 1
>  drop if incoming port was 2
>
> Is it possible to do such an implementation using ip_pipeline application?
> If so, how can I do that?
>
> Thanks for your reply and help.
>
> Thanks,
> Nidhia Varghese
>

Re: [dpdk-users] [dpdk-dev] Fwd: Sharing tables among pipelines

[Shyam Shrivastav]

Something I have gathered reading through code if it helps, ip_pipeline is
designed such that user side cli (_fe) runs in master pipeline and sends
conf requests to various other packet processing pipelines (_be) which
handle such requests at intervals. These can run on same or different
threads(cores) as per conf, no locking requirement as table-updation &
table-reading (packet processing) always happens in same pipeline so always
same thread. Master pipeline can be configured to run on a separate core &
it should be the case, but table updation happens in pipeline thread only
at lower priority.



On Tue, May 9, 2017 at 11:29 PM, Nidhia Varghese  wrote:

> Hi all,
>
> Thanks for your reply.
>
> As given in the link(3rd point), what I need is single writer
> thread(pipeline) performing table entry add/delete operations and another
> thread(which is in turn another pipeline) that performs lookup operations
> to the same table entries.
>
>
> Thanks,
> Nidhia Varghese
>

Re: [dpdk-users] RSS for non IP protocols

[Shyam Shrivastav]

No for 82599 as per my understanding , have a look at section 7.1.2.8.1 in
data sheet at

http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/82599-10-gbe-controller-datasheet.pdf

On Fri, May 5, 2017 at 1:30 AM, suryanathan p 
wrote:

> Hi,
>
> Is there a way we can enable RSS for non IP protocols? By disabling RSS,
> all the packets are queued to rx queue 0. I tried the ETH_RSS_L2_PAYLOAD
> option and that don't seem to help on either the 82599 or the X710
> controllers.
>
> Regards,
> Suryanathan P
>

Re: [dpdk-users] [dpdk-dev] DPDK Installation

[Shyam Shrivastav]

-d...@dpdk.org,+users@dpdk.org

http://dpdk.org/doc contains dpdk documents. Error you are lisitng is apt
(see man apt) related, you need to configure apt sources list to be able to
download & install packages in ubuntu. Any error, it is better to first
just google about it..
Also better place is users@dpdk.org for such queries

On Thu, Mar 30, 2017 at 1:13 AM, Ashwini Thaokar 
wrote:

> Hi,
>
> I have been trying to install dpdk on my VMware Fusion with Ubuntu 16.04.1
> on Mac. I've got many errors and tried troubleshooting but still I am not
> able to run the hello world example application. I'm thinking of starting
> from scratch.
> Please suggest me some link on how to install DPDK and run a sample
> application.
>
> The excerpt from my last error is below:
>
> You must put some 'source' URIs in your sources.list
>
> Thanks,
> Ashwini
>

Re: [dpdk-users] ip_pipeline firewall port filtering

[Shyam Shrivastav]

Port range filtering like in example configuration below is not working at
all for me, tried with two versions. Please help me as the corresponding
acl code is difficult, taking time to understand/debug ...

On Fri, Mar 17, 2017 at 11:34 AM, Shyam Shrivastav <
shrivastav.sh...@gmail.com> wrote:

> Hi
>
> I am trying to just allow tcp dest port 80 packets using ip_pipeline
> firewall, configured as under
> 
> 
> pipeline> p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 80
> 80 6 0xF port 0
> pipeline> p 1 firewall ls
> Prio = 1 (SA = 0.0.0.0/0, DA = 0.0.0.0/0, SP = 0-65535, DP = 80-80, Proto
> = 6 / 0xf) => Port = 0 (entry ptr = 0x7fddf9f0ff08)
> Default rule: DROP
> 
> ---
>
> but it is not working and all tcp packets are getting dropped. If I
> configure dest port range to be wildcard(0-65535) then tcp packets are
> allowed
>
> 
> ---
> pipeline> p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 0
> 65535 6 0xF port 0
> Prio = 1 (SA = 0.0.0.0/0, DA = 0.0.0.0/0, SP = 0-65535, DP = 0-65535,
> Proto = 6 / 0xf) => Port = 0 (entry ptr = 0x7fddf9f0ff08)
> pipeline> p 1 firewall ls
> Prio = 1 (SA = 0.0.0.0/0, DA = 0.0.0.0/0, SP = 0-65535, DP = 0-65535,
> Proto = 6 / 0xf) => Port = 0 (entry ptr = 0x7fddf9f0ff08)
> Default rule: DROP
>
> 
> --
>
> Has anyone got specific port filtering work with ip_pipeline firewall?
> I am debugging this, meanwhile any help/guidance would be greatly
> appreciated.
>
> Thanks and rgds
> Shyam
>

[dpdk-users] ip_pipeline firewall : fragmented ipv4 packets handling

[Shyam Shrivastav]

Again sending this issue as no response on original post. As per my
understanding if we are supporting ACL on tcp/usp port ranges then ipv4
packets must be reassembled before  checking against ACL, then fragmented
if required during forwarding. So there are three cases

1) My understanding is wrong then please correct me.
2) We correct this in examples wherever we are supporting access control on
udp/tcp ports.
3) We document this clearly.


-
Below is my original post

-
Hi All

Filtering based on TCP/UDP fields like src/dest port range works correctly
only on non-fragmented packets , that means reassembly must be done before
packets hit firewall rules table. Also  packets must be fragmented before
transmission if larger than port mtu. This is unsupported currently, any
plans for this in near future?

Regards

[dpdk-users] RSS : All fragments to same Recv queue

[Shyam Shrivastav]

Hi

We want to use RSS supported by intel 82599 NIC, with one lcore running on
each processor and handling one receive queue. All fragments of an ipv4
packet need to go to same receive queue and handled by same lcore for
lockless reassembly. Looks like Intel  82599 supports RSS IPv4 hashing
using just source and dest address fields and that should put all fragments
on same queue ( can be enabled by ETH_RSS_IPV4 in rte_eth_rss_conf->rs_hf).
Please let me know whether my understanding is correct.

Thanks
Shyam

[dpdk-users] ip_pipeline firewall customization

[Shyam Shrivastav]

Hello friends

I am using ip_pipeline firewall as base for our project, need
comments/suggestions/corrections regarding following

1) We can not configure firewall  rule to drop packets, as portid is
mandatory in command. I am planning to allow this for our requirement with
following code changes
  a) Allow "port" as optional parameter (pipeline_firewall.c), pass -1
as port id if "port" is not specified to app_pipeline_firewall_add_rule and
change that parameter to int32_t.
  b) Make required changes in pipeline_firewall_msg_req_add_handler if
portid is -1, that is table entry action to be .action =
RTE_PIPELINE_ACTION_DROP.

2) I am registering a f_action_hit function for firewall table to perform
certain translations if action is pass (RTE_PIPELINE_ACTION_PORT).
Configured a rule like following

pipeline>p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 0
65535 0 0 port 0

which should be hit only by ipv4 packets. However even ARP packets are hit
by this ACL and my routine is called. If I configure a specific src or dst
ip then everything works fine and arp packets are not hit , for example
following rule hits only ipv4 icmp packets

pipeline>  p 1 firewall add priority 1 ipv4 0.0.0.0 0 45.35.70.12 32 0
65535 0 65535 1 0xf port 0

Is this a bug or am I missing something ?

Best regards
Shyam

Re: [dpdk-users] Unable to bind intel NIC 82599ES to vfio-pci, uio_pci_generic

[Shyam Shrivastav]

Thanks Ferruh, I figured my mistake immediately afterwards. I am able to
work with uio_pci_generic and proceeding with my project pilot for now,
have not spent much time on debugging vfio-pci issue.

Here is one more try to bind vfio-pci, includes dmesg


[root@unassigned dpdk-16.11]# dpdk-devbind --status

Network devices using DPDK-compatible driver

:01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection'
drv=uio_pci_generic unused=ixgbe,igb_uio,vfio-pci

Network devices using kernel driver
===
:02:00.0 'I210 Gigabit Network Connection' if=eno1 drv=igb
unused=igb_uio,vfio-pci,uio_pci_generic
:03:00.0 'I210 Gigabit Network Connection' if=eno2 drv=igb
unused=igb_uio,vfio-pci,uio_pci_generic

Other network devices
=
:01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection'
unused=ixgbe,igb_uio,vfio-pci,uio_pci_generic

Crypto devices using DPDK-compatible driver
===


Crypto devices using kernel driver
==


Other crypto devices



[root@unassigned dpdk-16.11]# dpdk-devbind -b vfio-pci 01:00.1
Error: bind failed for :01:00.1 - Cannot bind to driver vfio-pci

[root@unassigned dpdk-16.11]# dmesg | tail -n 10
[ 1989.451194] VFIO - User Level meta-driver version: 0.3
[16700.417269] VFIO - User Level meta-driver version: 0.3
[16708.620870] rte_kni: loading out-of-tree module taints kernel.
[16708.621016] rte_kni: module verification failed: signature and/or
required key missing - tainting kernel
[16762.831711] igb_uio: Use MSIX interrupt by default
[378754.897617] Intel(R) 10GbE PCI Express Linux Network Driver - version
4.5.4
[378754.897623] Copyright(c) 1999 - 2016 Intel Corporation.
[491762.064211] Intel(R) 10GbE PCI Express Linux Network Driver - version
4.5.4
[491762.064213] Copyright(c) 1999 - 2016 Intel Corporation.
[515594.211309] VFIO - User Level meta-driver version: 0.3

[root@unassigned dpdk-16.11]# ulimit -l
unlimited


dmesg for initialisation check

[root@unassigned dpdk-16.11]# dmesg | grep DMAR
[0.00] ACPI: DMAR 7d705e98 00070 (v01 INTEL  SKL
0001 INTL 0001)
[0.00] DMAR: IOMMU enabled
[0.027917] DMAR: Host address width 39
[0.027918] DMAR: DRHD base: 0x00fed9 flags: 0x1
[0.027923] DMAR: dmar0: reg_base_addr fed9 ver 1:0 cap
d2008c40660462 ecap f050da
[0.027923] DMAR: RMRR base: 0x007d19 end: 0x007d1a
[0.027925] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed9 IOMMU 0
[0.027926] DMAR-IR: HPET id 0 under DRHD base 0xfed9
[0.027927] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out
bit.
[0.027927] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the
BIOS setting.
[0.028288] DMAR-IR: Enabled IRQ remapping in xapic mode
[0.511886] DMAR: No ATSR found
[0.511942] DMAR: dmar0: Using Queued invalidation
[0.511954] DMAR: Hardware identity mapping for device :00:00.0
[0.511955] DMAR: Hardware identity mapping for device :00:01.0
[0.511956] DMAR: Hardware identity mapping for device :00:14.0
[0.511957] DMAR: Hardware identity mapping for device :00:14.2
[0.511958] DMAR: Hardware identity mapping for device :00:16.0
[0.511959] DMAR: Hardware identity mapping for device :00:17.0
[0.511959] DMAR: Hardware identity mapping for device :00:1d.0
[0.511960] DMAR: Hardware identity mapping for device :00:1d.1
[0.511961] DMAR: Hardware identity mapping for device :00:1d.2
[0.511962] DMAR: Hardware identity mapping for device :00:1f.0
[0.511963] DMAR: Hardware identity mapping for device :00:1f.2
[0.511964] DMAR: Hardware identity mapping for device :00:1f.4
[0.511965] DMAR: Hardware identity mapping for device :01:00.0
[0.511966] DMAR: Hardware identity mapping for device :01:00.1
[0.511969] DMAR: Hardware identity mapping for device :02:00.0
[0.511971] DMAR: Hardware identity mapping for device :03:00.0
[0.511972] DMAR: Setting RMRR:
[0.511973] DMAR: Ignoring identity map for HW passthrough device
:00:14.0 [0x7d19 - 0x7d1a]
[0.511974] DMAR: Prepare 0-16MiB unity mapping for LPC
[0.511975] DMAR: Ignoring identity map for HW passthrough device
:00:1f.0 [0x0 - 0xff]
[0.511976] DMAR: Intel(R) Virtualization Technology for Directed I/O
[root@unassigned dpdk-16.11]#





On Mon, Feb 13, 2017 at 10:31 PM, Ferruh Yigit <ferruh.yi...@intel.com>
wrote:

> On 2/8/2017 7:19 AM, Shyam Shrivastav wrote:
> > Hi All
> >
> > I am not able to bind 82599 to either uio_pci_generic or vfio-pci
> > successfully. Any help greatly appreciated, I am completely stuck at this
> > initial step.
> >
> > *1) uio_pci_generic* : tools/dpdk-devbind.py script reports success but
> it
> > 

Re: [dpdk-users] Unable to bind intel NIC 82599ES to vfio-pci, uio_pci_generic

[Shyam Shrivastav]

Please ignore my previous messages. I was using command line options
wrongly, being my first day with dpdk, missed the "--" separating EAL and
app options, caught it only going through code !
Still I am unable to make vfio-pci work bind to ports, uio_pci_generic as
well as igb_uio are working.

Thanks and rgds
Shyam

[dpdk-users] Unable to bind intel NIC 82599ES to vfio-pci, uio_pci_generic

[Shyam Shrivastav]

Hi All

I am not able to bind 82599 to either uio_pci_generic or vfio-pci
successfully. Any help greatly appreciated, I am completely stuck at this
initial step.

*1) uio_pci_generic* : tools/dpdk-devbind.py script reports success but it
is not detected by EAL on initialisation, still ixgbe driver is detected.
here is relevant console output

[root@unassigned dpdk-16.11]# tools/dpdk-devbind.py --status

Network devices using DPDK-compatible driver

:01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection'
drv=uio_pci_generic unused=ixgbe,vfio-pci
:01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection'
drv=uio_pci_generic unused=ixgbe,vfio-pci

[root@unassigned dpdk-16.11]# examples/l2fwd/build/l2fwd  -c f -n 2 p 
EAL: Detected 8 lcore(s)
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: VFIO support initialized
EAL: PCI device :01:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10fb net_ixgbe
EAL: PCI device :01:00.1 on NUMA socket -1
EAL:   probe driver: 8086:10fb net_ixgbe
EAL: PCI device :02:00.0 on NUMA socket -1
EAL:   probe driver: 8086:1533 net_e1000_igb
EAL: PCI device :03:00.0 on NUMA socket -1
EAL:   probe driver: 8086:1533 net_e1000_igb
MAC updating enabled
Skipping disabled port 0
Skipping disabled port 1
EAL: Error - exiting with code: 1
  Cause: All available ports are disabled. Please set portmask.



*2) vfio-pci :* Configured vfio permissions using setup.sh, bind script
reports error in this case as under

[root@unassigned dpdk-16.11]# tools/dpdk-devbind.py --force -b vfio-pci
01:00.0 01:00.1
Error: bind failed for :01:00.0 - Cannot bind to driver vfio-pci
Error: bind failed for :01:00.1 - Cannot bind to driver vfio-pci

Here is relevant configuration for this to work

[root@unassigned dpdk-16.11]# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-3.10.0-514.6.1.el7.x86_64
root=UUID=814b781b-1955-4b34-81d6-5c5360325c2e ro crashkernel=auto rhgb
quiet intel_iommu=on iommu=pt
[root@unassigned dpdk-16.11]# dmesg|grep IOMMU
[0.00] DMAR: IOMMU enabled
[0.027925] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed9 IOMMU 0
[root@unassigned dpdk-16.11]# ulimit -l
unlimited
[root@unassigned dpdk-16.11]# lsmod|grep pci
vfio_pci   37039  0
vfio   26136  2 vfio_iommu_type1,vfio_pci
irqbypass  13503  2 kvm,vfio_pci
uio_pci_generic12588  0
uio19259  1 uio_pci_generic


Thanks
Shyam

[dpdk-users] Port binding issues : NIC intel 82599ES

[Shyam Shrivastav]

Hi
I just started on dpdk, was trying to run l2fw. I bind two 82599 ports
using dpdk-devbind to igb_uio (first tried uio_pci_generic with same
result), then run l2fw but EAL is unable to probe these drivers still
getting ixgbe. Here is the console output

[root@unassigned build]# dpdk-devbind --status

Network devices using DPDK-compatible driver

:01:00.0 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio
unused=ixgbe,uio_pci_generic
:01:00.1 '82599ES 10-Gigabit SFI/SFP+ Network Connection' drv=igb_uio
unused=ixgbe,uio_pci_generic

Network devices using kernel driver
===
:02:00.0 'I210 Gigabit Network Connection' if=eno1 drv=igb
unused=igb_uio,uio_pci_generic
:03:00.0 'I210 Gigabit Network Connection' if=eno2 drv=igb
unused=igb_uio,uio_pci_generic

Other network devices
=


Crypto devices using DPDK-compatible driver
===


Crypto devices using kernel driver
==


Other crypto devices


[root@unassigned build]# ./l2fwd -c f -n 2 p 
EAL: Detected 8 lcore(s)
EAL: No free hugepages reported in hugepages-1048576kB
EAL: Probing VFIO support...
EAL: PCI device :01:00.0 on NUMA socket -1
EAL:   probe driver: 8086:10fb net_ixgbe
EAL: PCI device :01:00.1 on NUMA socket -1
EAL:   probe driver: 8086:10fb net_ixgbe
EAL: PCI device :02:00.0 on NUMA socket -1
EAL:   probe driver: 8086:1533 net_e1000_igb
EAL: PCI device :03:00.0 on NUMA socket -1
EAL:   probe driver: 8086:1533 net_e1000_igb
MAC updating enabled
Skipping disabled port 0
Skipping disabled port 1
EAL: Error - exiting with code: 1
  Cause: All available ports are disabled. Please set portmask.
[root@unassigned build]#