* Re: [PATCH v10 1/6] ethdev: add Tx preparation
From: Kulasek, TomaszX @ 2016-10-25 17:28 UTC (permalink / raw)
To: Olivier Matz, dev@dpdk.org; +Cc: Ananyev, Konstantin
In-Reply-To: <e86291cd-f970-c0c5-4a3b-6da62516ce6a@6wind.com>
> -----Original Message-----
> From: Olivier Matz [mailto:olivier.matz@6wind.com]
> Sent: Tuesday, October 25, 2016 16:42
> To: Kulasek, TomaszX <tomaszx.kulasek@intel.com>; dev@dpdk.org
> Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>
> Subject: Re: [PATCH v10 1/6] ethdev: add Tx preparation
>
> Hi Tomasz,
>
> On 10/24/2016 06:51 PM, Tomasz Kulasek wrote:
> > Added API for `rte_eth_tx_prep`
> >
> > [...]
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -182,6 +182,7 @@ extern "C" {
> > #include <rte_pci.h>
> > #include <rte_dev.h>
> > #include <rte_devargs.h>
> > +#include <rte_errno.h>
> > #include "rte_ether.h"
> > #include "rte_eth_ctrl.h"
> > #include "rte_dev_info.h"
> > @@ -699,6 +700,8 @@ struct rte_eth_desc_lim {
> > uint16_t nb_max; /**< Max allowed number of descriptors. */
> > uint16_t nb_min; /**< Min allowed number of descriptors. */
> > uint16_t nb_align; /**< Number of descriptors should be aligned to.
> > */
> > + uint16_t nb_seg_max; /**< Max number of segments per whole
> packet. */
> > + uint16_t nb_mtu_seg_max; /**< Max number of segments per one MTU */
>
> Sorry if it was not clear in my previous review, but I think this should
> be better explained here. You said that the "limitation of number of
> segments may differ depend of TSO/non TSO".
>
> As an application developer, I still have some difficulties to clearly
> understand what does that mean. Is it the maximum number of mbuf-segments
> that contain payload for one tcp-segment sent by the device?
>
> In that case, it looks quite difficult to verify that in an application.
> It looks that this field is not used by validate_offload(), so how should
> it be used by an application?
>
E.g. for i40e (from xl710 datasheet):
8.4.1 Transmit Packet in System Memory
...
A few rules related to the transmit packet in host memory are:
...
- A single transmit packet may span up to 8 buffers (up to 8 data descriptors
per packet including both the header and payload buffers).
- The total number of data descriptors for the whole TSO (explained later on in
this chapter) is unlimited as long as each segment within the TSO obeys
the previous rule (up to 8 data descriptors per segment for both the TSO
header and the segment payload buffers).
...
+#define I40E_TX_MAX_SEG UINT8_MAX
+#define I40E_TX_MAX_MTU_SEG 8
For ixgbe driver there's one limitation, both for TSO and non-TSO and it
is always 40-WTHRESH.
Such a differences causes that these values should checked in the tx_prep
callback (when it is required) for a specific device (e.g. i40e, ixgbe).
If other device have not such a limitations, or are higher than DPDK can
handle (nb_segs is uint8_t), then for performance reason it doesn't need
to be checked.
Validate_offload() is for general check, the drivers specific implementation
Is the part in the callback function e.g. in
uint16_t ixgbe_prep_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
uint16_t nb_pkts)
for ixgbe.
Values in the "struct rte_eth_desc_lim" provides an information to the
application, which should to let you to not create malicious packets or
at least to limit their number.
Using Tx preparation API, these checks are made transparently for the
application and when nb_segs are out of limits, tx_prep function fails.
>
> > };
> >
> > /**
> > @@ -1188,6 +1191,11 @@ typedef uint16_t (*eth_tx_burst_t)(void *txq,
> > uint16_t nb_pkts);
> > /**< @internal Send output packets on a transmit queue of an Ethernet
> > device. */
> >
> > +typedef uint16_t (*eth_tx_prep_t)(void *txq,
> > + struct rte_mbuf **tx_pkts,
> > + uint16_t nb_pkts);
> > +/**< @internal Prepare output packets on a transmit queue of an
> > +Ethernet device. */
> > +
> > typedef int (*flow_ctrl_get_t)(struct rte_eth_dev *dev,
> > struct rte_eth_fc_conf *fc_conf); /**< @internal
> Get
> > current flow control parameter on an Ethernet device */ @@ -1622,6
> > +1630,7 @@ struct rte_eth_rxtx_callback { struct rte_eth_dev {
> > eth_rx_burst_t rx_pkt_burst; /**< Pointer to PMD receive function.
> */
> > eth_tx_burst_t tx_pkt_burst; /**< Pointer to PMD transmit function.
> > */
> > + eth_tx_prep_t tx_pkt_prep; /**< Pointer to PMD transmit prepare
> > +function. */
> > struct rte_eth_dev_data *data; /**< Pointer to device data */
> > const struct eth_driver *driver;/**< Driver for this device */
> > const struct eth_dev_ops *dev_ops; /**< Functions exported by PMD */
> > @@ -2816,6 +2825,93 @@ rte_eth_tx_burst(uint8_t port_id, uint16_t
> queue_id,
> > return (*dev->tx_pkt_burst)(dev->data->tx_queues[queue_id], tx_pkts,
> > nb_pkts); }
> >
> > +/**
> > + * Process a burst of output packets on a transmit queue of an Ethernet
> device.
> > + *
> > + * The rte_eth_tx_prep() function is invoked to prepare output
> > +packets to be
> > + * transmitted on the output queue *queue_id* of the Ethernet device
> > +designated
> > + * by its *port_id*.
> > + * The *nb_pkts* parameter is the number of packets to be prepared
> > +which are
> > + * supplied in the *tx_pkts* array of *rte_mbuf* structures, each of
> > +them
> > + * allocated from a pool created with rte_pktmbuf_pool_create().
> > + * For each packet to send, the rte_eth_tx_prep() function performs
> > + * the following operations:
> > + *
> > + * - Check if packet meets devices requirements for tx offloads.
> > + *
> > + * - Check limitations about number of segments.
> > + *
> > + * - Check additional requirements when debug is enabled.
> > + *
> > + * - Update and/or reset required checksums when tx offload is set for
> packet.
> > + *
> > + * The rte_eth_tx_prep() function returns the number of packets ready
> > +to be
> > + * sent. A return value equal to *nb_pkts* means that all packets are
> > +valid and
> > + * ready to be sent.
> > + *
> > + * @param port_id
> > + * The port identifier of the Ethernet device.
> > + * The value must be a valid port id.
> > + * @param queue_id
> > + * The index of the transmit queue through which output packets must
> be
> > + * sent.
> > + * The value must be in the range [0, nb_tx_queue - 1] previously
> supplied
> > + * to rte_eth_dev_configure().
> > + * @param tx_pkts
> > + * The address of an array of *nb_pkts* pointers to *rte_mbuf*
> structures
> > + * which contain the output packets.
> > + * @param nb_pkts
> > + * The maximum number of packets to process.
> > + * @return
> > + * The number of packets correct and ready to be sent. The return
> value can be
> > + * less than the value of the *tx_pkts* parameter when some packet
> doesn't
> > + * meet devices requirements with rte_errno set appropriately.
> > + */
>
> Inserting here the previous comment:
>
> >> Can we add the constraint that invalid packets are left untouched?
> >>
> >> I think most of the time there will be a software fallback in that
> >> case, so it would be good to ensure that this function does not
> >> change the flags or the packet data.
> >
> > In current implementation, if packet is invalid, its data is never
> modified. Only checks are done. The only exception is when checksum needs
> to be updated or initialized, but it's done after packet validation.
> > If we want to use/restore packet in application it didn't should be
> changed in any way for invalid packets.
> >
>
> I think this should be explicitly said in the API comment that valid
> packets may be modified (*), but invalid packets (whose index is >= than
> the return value) are left untouched.
>
> (*) we still need to discuss that point, see below.
>
> Another comment was made:
>
> >> Another thing that could be interesting for the caller is to know the
> >> reason of the failure. Maybe the different errno types could be
> >> detailed here. For instance:
> >> - EINVAL: offload flags are not correctly set (i.e. would fail whatever
> >> the hardware)
> >> - ENOTSUP: the offload feature is not supported by the hardware
> >> - ...
> >>
> >
> > Ok.
>
> Don't you feel it could go in the API comment too?
>
Ok, I will modify comments.
>
> > [...]
> >
> > +/**
> > + * Fix pseudo header checksum
> > + *
> > + * This function fixes pseudo header checksum for TSO and non-TSO
> > +tcp/udp in
> > + * provided mbufs packet data.
> > + *
> > + * - for non-TSO tcp/udp packets full pseudo-header checksum is counted
> and set
> > + * in packet data,
> > + * - for TSO the IP payload length is not included in pseudo header.
> > + *
> > + * This function expects that used headers are in the first data
> > +segment of
> > + * mbuf, and are not fragmented.
>
> There is another requirement about the cloning and reference count.
> Sorry I did not answer to Konstantin, but I still think this could be an
> issue.
>
> For instance, I think that the zero-copy mode of vhost application
> references the packet sent by the guest and send the data. The payload
> should not be modified because it is in guest memory (we don't know, maybe
> the guest also cloned it for its own purpose).
>
> It means that the tx_prep() API must not be used with clones, i.e the
> headers must not reside in a segment whose RTE_MBUF_INDIRECT(seg) or
> rte_mbuf_refcnt_read(seg) > 1.
>
> - if we really want this API in 16.11, it should be clearly explained
> in the API comment that it does not work with shared segments
>
Ok, I will.
> - for next versions, we have to take a decision whether it should be
> supported or not. In my opinion, cloned packets are useful and should
> be supported properly by all dpdk APIs.
>
>
> Thanks,
> Olivier
Thanks,
Tomasz
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-10-25 17:49 UTC (permalink / raw)
To: dev
Cc: thomas.monjalon, bruce.richardson, narender.vangati,
hemant.agrawal, gage.eads
In-Reply-To: <1476214216-31982-1-git-send-email-jerin.jacob@caviumnetworks.com>
On Wed, Oct 12, 2016 at 01:00:16AM +0530, Jerin Jacob wrote:
> Thanks to Intel and NXP folks for the positive and constructive feedback
> I've received so far. Here is the updated RFC(v2).
>
> I've attempted to address as many comments as possible.
>
> This series adds rte_eventdev.h to the DPDK tree with
> adequate documentation in doxygen format.
>
> Updates are also available online:
>
> Related draft header file (this patch):
> https://rawgit.com/jerinjacobk/libeventdev/master/rte_eventdev.h
>
> PDF version(doxgen output):
> https://rawgit.com/jerinjacobk/libeventdev/master/librte_eventdev_v2.pdf
>
> Repo:
> https://github.com/jerinjacobk/libeventdev
>
Hi Community,
So far, I have received constructive feedback from Intel, NXP and Linaro folks.
Let me know, if anyone else interested in contributing to the definition of eventdev?
If there are no major issues in proposed spec, then Cavium would like work on
implementing and up-streaming the common code(lib/librte_eventdev/) and
an associated HW driver.(Requested minor changes of v2 will be addressed
in next version).
We are planning to submit the work for 17.02 or 17.05 release(based on
how implementation goes).
/Jerin
Cavium
^ permalink raw reply
* Re: [PATCH v2] app/testpmd: fix PF/VF check of flow director
From: Thomas Monjalon @ 2016-10-25 21:08 UTC (permalink / raw)
To: Wenzhuo Lu; +Cc: dev
In-Reply-To: <1476839535-1220-1-git-send-email-wenzhuo.lu@intel.com>
2016-10-19 09:12, Wenzhuo Lu:
> Parameters pf & vf are added into most of flow director
> filter CLIs.
> But mac-valn and tunnel filters don't have these parameters,
> the parameters should not be checked for mac-vlan and tunnel
> filters.
>
> Fixes: e6a68c013353 ("app/testpmd: extend commands for flow director in VF")
>
> Signed-off-by: Wenzhuo Lu <wenzhuo.lu@intel.com>
> Acked-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
This bug was reported and fixed by Frederico Cadete:
http://dpdk.org/patch/15264
We have waited long to have a review saying it requires
an optional parameter in the command line.
And finally you re-post a fixed version of the same approach
without any comment to the original thread or a reference here.
Please be more careful with occasional contributors.
Applied with
Reported-by: Frederico Cadete <frederico.cadete-ext@oneaccess-net.com>
^ permalink raw reply
* Re: [PATCH] testpmd: fix fdir command on MAC and tunnel modes
From: Thomas Monjalon @ 2016-10-25 21:14 UTC (permalink / raw)
To: Frederico Cadete, Frederico.Cadete-ext@oneaccess-net.com; +Cc: dev
In-Reply-To: <CAL5ScNVyW=UU9A_X6BJ+BA53bkae=4W-OLqO31FHQgEynNHmsw@mail.gmail.com>
2016-09-27 11:01, Frederico Cadete:
> On Tue, Sep 27, 2016 at 4:42 AM, Wu, Jingjing <jingjing.wu@intel.com> wrote:
> > From: Frederico.Cadete-
> >> The flow_director_filter commands has a pf|vf option for most modes
> >> except for MAC-VLAN and tunnel. On Intel NIC's these modes are not
> >> supported under virtualized environments.
> >> But the application was checking that this field was parsed for these cases,
> >> even though this token is not registered with the cmdline parser.
> >>
> >> This patch skips checking of this field for the commands that don't accept it.
> >>
> >> Signed-off-by: Frederico Cadete <Frederico.Cadete-ext@oneaccess-net.com>
[...]
> >
> > Thanks for the patch.
>
> And thanks a lot for the review.
>
> > But with this change the field of pf_vf cannot omit either.
> > I think it still looks confused because it will allow any meaningless string.
>
> Sorry, I am not aware that it can be omitted.
> For MAC/VLAN and tunnel mode it does not and will not allow any
> meaningless string.
> At least that was my intention :)
>
> The cmdline parser expects "... flexbytes (flexbytes_value) (drop|fwd)
> queue ..." .
> This is what is documented [1] and the command's cmdline_parse_inst_t
> [2] matches this.
> If you put something in-between "(drop|fwd)" and "queue" it is
> rejected by the parser
> in librte_cmdline.
>
> > In MAC_VLAN or TUNNEL mode, why not just use pf.
>
> With the current code, because if you write that in the command, it is
> rejected by the parser :)
>
> Do you mean it would be preferable to make these commands always take
> such an argument,
> and only at the NIC driver check that it must equal PF for MAC_VLAN or
> TUNNEL mode?
> The command becomes a bit more complicated for the current intel
> NIC's, but as I understand
> it currently does not work anyway. Unless I'm missing something else.
>
> >
> > Maybe an optional field supporting on DPDK cmdline library is exactly what we
> > Are waiting for :)
>
> Laudable goal! My excuses but it's beyond my current skills and bandwith :/
Thanks Frederico.
Your approach has been re-submitted and fixed by Wenzhuo:
http://dpdk.org/patch/16679
^ permalink raw reply
* Re: [dpdk-stable] [PATCH v2] mempool: fix search of maximum contiguous pages
From: Thomas Monjalon @ 2016-10-25 21:23 UTC (permalink / raw)
To: Olivier Matz, wei.dai; +Cc: dev, stable
In-Reply-To: <1477407671-21019-1-git-send-email-olivier.matz@6wind.com>
2016-10-25 17:01, Olivier Matz:
> From: Wei Dai <wei.dai@intel.com>
>
> paddr[i] + pg_sz always points to the start physical address of the
> 2nd page after pddr[i], so only up to 2 pages can be combinded to
> be used. With this revision, more than 2 pages can be used.
>
> Fixes: 84121f197187 ("mempool: store memory chunks in a list")
>
> Signed-off-by: Wei Dai <wei.dai@intel.com>
> Signed-off-by: Olivier Matz <olivier.matz@6wind.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v2] lib/ether: prevent duplicate callback on list
From: Thomas Monjalon @ 2016-10-25 21:35 UTC (permalink / raw)
To: E. Scott Daniels; +Cc: dev
In-Reply-To: <1476970481-21034-1-git-send-email-daniels@research.att.com>
2016-10-20 09:34, E. Scott Daniels:
> This change prevents the attempt to add a structure which is
> already on the callback list. If a struct with matching
> parameters is found on the list, then no action is taken. If
> a struct with matching parameters is found on the list, then
> no action is taken.
Callback is not duplicate anymore but the last sentence is duplicate :)
> Fixes: ac2f69c ("ethdev: fix crash if malloc of user callback fails")
>
> Signed-off-by: E. Scott Daniels <daniels@research.att.com>
> ---
>
> V2:
> * Correct the component name; changed from net/ixgbe.
> * Add Fixes tag.
> * Acked-by: Wenzhuo Lu <Wenzhuo.lu@intel.com>
The Acked-by tag must be added below your Signed-off-by.
Applied with above nits fixed, thanks
^ permalink raw reply
* [PATCH] pci: Don't call probe callback if driver already loaded.
From: Ben Walker @ 2016-10-25 21:50 UTC (permalink / raw)
To: dev
If the user asks to probe multiple times, the probe
callback should only be called on devices that don't have
a driver already loaded.
This is useful if a driver is registered after the
execution of a program has started and the list of devices
needs to be re-scanned.
Signed-off-by: Ben Walker <benjamin.walker@intel.com>
---
lib/librte_eal/common/eal_common_pci.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/lib/librte_eal/common/eal_common_pci.c b/lib/librte_eal/common/eal_common_pci.c
index 638cd86..971ad20 100644
--- a/lib/librte_eal/common/eal_common_pci.c
+++ b/lib/librte_eal/common/eal_common_pci.c
@@ -289,6 +289,10 @@ pci_probe_all_drivers(struct rte_pci_device *dev)
if (dev == NULL)
return -1;
+ /* Check if a driver is already loaded */
+ if (dev->driver != NULL)
+ return 0;
+
TAILQ_FOREACH(dr, &pci_driver_list, next) {
rc = rte_eal_pci_probe_one_driver(dr, dev);
if (rc < 0)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v7 3/7] vhost: simplify mergeable Rx vring reservation
From: Thomas Monjalon @ 2016-10-25 22:08 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev
In-Reply-To: <1476437678-7102-4-git-send-email-yuanhan.liu@linux.intel.com>
2016-10-14 17:34, Yuanhan Liu:
> -static inline uint32_t __attribute__((always_inline))
> +static inline int __attribute__((always_inline))
> copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
> - uint16_t end_idx, struct rte_mbuf *m,
> - struct buf_vector *buf_vec)
> + struct rte_mbuf *m, struct buf_vector *buf_vec,
> + uint16_t num_buffers)
> {
> struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0};
> uint32_t vec_idx = 0;
> - uint16_t start_idx = vq->last_used_idx;
> - uint16_t cur_idx = start_idx;
> + uint16_t cur_idx = vq->last_used_idx;
> uint64_t desc_addr;
> uint32_t desc_chain_head;
> uint32_t desc_chain_len;
> @@ -394,21 +393,21 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
> struct rte_mbuf *hdr_mbuf;
>
> if (unlikely(m == NULL))
> - return 0;
> + return -1;
>
> LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
> dev->vid, cur_idx, end_idx);
There is a build error:
lib/librte_vhost/virtio_net.c:399:22: error: ‘end_idx’ undeclared
It is probably trivial and could be fixed directly in the already applied
commit in next-virtio.
^ permalink raw reply
* DPDK & ASLR
From: Samir Shah @ 2016-10-25 22:18 UTC (permalink / raw)
To: dev
We know that it is recommended that ASLR be turned off so that the mappings
across primary and secondary remain the same.
Does ASLR need to be turned off system-wide, or DPDK-processes wide? Could
we use setarch/personality to disable ASLR for just the DPDK process and
leave it enabled for the rest of the system? Any experience to say if that
would work or not?
- Samir
^ permalink raw reply
* Re: [PATCH] examples/ipsec-secgw: Update checksum while decrementing ttl
From: De Lara Guarch, Pablo @ 2016-10-26 2:29 UTC (permalink / raw)
To: Akhil Goyal, Gonzalez Monroy, Sergio, dev@dpdk.org
In-Reply-To: <DB3PR04MB10743C10BC39E6D154FA82DE6D20@DB3PR04MB107.eurprd04.prod.outlook.com>
> -----Original Message-----
> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> Sent: Wednesday, October 19, 2016 1:38 AM
> To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio; dev@dpdk.org
> Subject: RE: [PATCH] examples/ipsec-secgw: Update checksum while
> decrementing ttl
>
>
>
> -----Original Message-----
> From: De Lara Guarch, Pablo [mailto:pablo.de.lara.guarch@intel.com]
> Sent: Monday, October 17, 2016 10:35 PM
> To: Gonzalez Monroy, Sergio <sergio.gonzalez.monroy@intel.com>; Akhil
> Goyal <akhil.goyal@nxp.com>; dev@dpdk.org
> Subject: RE: [PATCH] examples/ipsec-secgw: Update checksum while
> decrementing ttl
>
>
>
> > -----Original Message-----
> > From: Gonzalez Monroy, Sergio
> > Sent: Monday, October 10, 2016 5:05 AM
> > To: De Lara Guarch, Pablo; Akhil Goyal; dev@dpdk.org
> > Subject: Re: [PATCH] examples/ipsec-secgw: Update checksum while
> > decrementing ttl
> >
> > On 07/10/2016 21:53, De Lara Guarch, Pablo wrote:
> > >> -----Original Message-----
> > >> From: Akhil Goyal [mailto:akhil.goyal@nxp.com]
> > >> Sent: Tuesday, October 04, 2016 11:33 PM
> > >> To: De Lara Guarch, Pablo; Gonzalez Monroy, Sergio; dev@dpdk.org
> > >> Subject: Re: [PATCH] examples/ipsec-secgw: Update checksum while
> > >> decrementing ttl
> > >>
> > >> On 10/5/2016 6:04 AM, De Lara Guarch, Pablo wrote:
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Sergio
> > Gonzalez
> > >>>> Monroy
> > >>>> Sent: Monday, September 26, 2016 6:28 AM
> > >>>> To: akhil.goyal@nxp.com; dev@dpdk.org
> > >>>> Subject: Re: [dpdk-dev] [PATCH] examples/ipsec-secgw: Update
> > checksum
> > >>>> while decrementing ttl
> > >>>>
> > >>>> Hi Akhil,
> > >>>>
> > >>>> This application relies on checksum offload in both outbound and
> > >> inbound
> > >>>> paths (PKT_TX_IP_CKSUM flag).
> > >> [Akhil]Agreed that the application relies on checksum offload, but
> > >> here we are talking about the inner ip header. Inner IP checksum
> > >> will be updated on the next end point after decryption. This would
> > >> expect that the next end point must have checksum offload
> > >> capability. What if we are capturing the encrypted packets on
> > >> wireshark or say send it to some other machine which does not run
> > >> DPDK and do not know about
> > checksum
> > >> offload, then wireshark/other machine will not be able to get the
> > >> correct the checksum and will show error.
> >
> > Understood, we need to have a valid inner checksum.
> > RFC1624 states that the computation would be incorrect in
> > corner/boundary case.
> > I reckon you are basing your incremental update on RFC1141?
> >
> > Also I think you should take care of endianess and increment the
> > checksum with
> > host_to_be(0x0100) instead of +1.
> >
> > >>>> Because we assume that we always forward the packet in both
> > >>>> paths,
> > we
> > >>>> decrement the ttl in both inbound and outbound.
> > >>>> You seem to only increment (recalculate) the checksum of the
> > >>>> inner IP header in the outbound path but not the inbound path.
> > >> [Akhil]Correct I missed out the inbound path.
> > >>>> Also, in the inbound path you have to consider a possible ECN
> > >>>> value
> > >> update.
> > >> [Akhil]If I take care of the ECN then it would mean I need to
> > >> calculate the checksum completely, incremental checksum wont give
> correct results.
> > >> This would surely impact performance. Any suggestion on how should
> > >> we take care of ECN update. Should I recalculate the checksum and
> > >> send the patch for ECN update? Or do we have a better solution.
> >
> > If I am understanding the RFCs mentioned above correctly, you should
> > be able to do incremental checksum update for any 16bit field/value of
> > the IP header.
> > I don't see no reason why you couldn't do something like that, except
> > that you would have to follow the full equation instead of just adding
> > 0x0100, which would be always the case when decrementing TTL.
> >
> > What do you think?
>
> Any comments, Akhil?
>
> Ok.. will send next version soon.
Hi Akhil,
Are you sending that version soon? It won't make it the RC2, but it may be merged for RC3.
Thanks,
Pablo
^ permalink raw reply
* Re: [PATCH v7 3/7] vhost: simplify mergeable Rx vring reservation
From: Yuanhan Liu @ 2016-10-26 2:56 UTC (permalink / raw)
To: Thomas Monjalon; +Cc: dev
In-Reply-To: <4827637.JFOYA5HLyK@xps13>
On Wed, Oct 26, 2016 at 12:08:49AM +0200, Thomas Monjalon wrote:
> 2016-10-14 17:34, Yuanhan Liu:
> > -static inline uint32_t __attribute__((always_inline))
> > +static inline int __attribute__((always_inline))
> > copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
> > - uint16_t end_idx, struct rte_mbuf *m,
> > - struct buf_vector *buf_vec)
> > + struct rte_mbuf *m, struct buf_vector *buf_vec,
> > + uint16_t num_buffers)
> > {
> > struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0};
> > uint32_t vec_idx = 0;
> > - uint16_t start_idx = vq->last_used_idx;
> > - uint16_t cur_idx = start_idx;
> > + uint16_t cur_idx = vq->last_used_idx;
> > uint64_t desc_addr;
> > uint32_t desc_chain_head;
> > uint32_t desc_chain_len;
> > @@ -394,21 +393,21 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev, struct vhost_virtqueue *vq,
> > struct rte_mbuf *hdr_mbuf;
> >
> > if (unlikely(m == NULL))
> > - return 0;
> > + return -1;
> >
> > LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
> > dev->vid, cur_idx, end_idx);
>
> There is a build error:
> lib/librte_vhost/virtio_net.c:399:22: error: ‘end_idx’ undeclared
Oops... you know, my robot is broken since the holiday :(
I just had a quick fix. Hopefully, it will start working again...
> It is probably trivial and could be fixed directly in the already applied
> commit in next-virtio.
Yes, and FYI, here is the overall diffs I made to fix this bug.
--yliu
---
diff --git a/lib/librte_vhost/virtio_net.c
b/lib/librte_vhost/virtio_net.c
index b784dba..eed0b1c 100644
--- a/lib/librte_vhost/virtio_net.c
+++ b/lib/librte_vhost/virtio_net.c
@@ -443,9 +443,6 @@ copy_mbuf_to_desc_mergeable(struct virtio_net *dev,
struct rte_mbuf *m,
if (unlikely(m == NULL))
return -1;
- LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
- dev->vid, cur_idx, end_idx);
-
desc_addr = gpa_to_vva(dev, buf_vec[vec_idx].buf_addr);
if (buf_vec[vec_idx].buf_len < dev->vhost_hlen || !desc_addr)
return -1;
@@ -555,6 +552,10 @@ virtio_dev_merge_rx(struct virtio_net *dev,
uint16_t queue_id,
break;
}
+ LOG_DEBUG(VHOST_DATA, "(%d) current index %d | end index %d\n",
+ dev->vid, vq->last_avail_idx,
+ vq->last_avail_idx + num_buffers);
+
if (copy_mbuf_to_desc_mergeable(dev, pkts[pkt_idx],
buf_vec, num_buffers) < 0) {
vq->shadow_used_idx -= num_buffers;
^ permalink raw reply
* Re: DPDK & ASLR
From: Jon DeVree @ 2016-10-26 4:20 UTC (permalink / raw)
To: dev
In-Reply-To: <CAJacC6ttgyPYSXYSO0EdHmWNLwLrzwC86Pex5bO5KS92LOd8_A@mail.gmail.com>
On Tue, Oct 25, 2016 at 15:18:03 -0700, Samir Shah wrote:
> Does ASLR need to be turned off system-wide, or DPDK-processes wide? Could
> we use setarch/personality to disable ASLR for just the DPDK process and
> leave it enabled for the rest of the system? Any experience to say if that
> would work or not?
>
I'm using setarch/personality to disable it only in the processes using
dpdk without any trouble.
--
Jon
Doge Wrangler
X(7): A program for managing terminal windows. See also screen(1) and tmux(1).
^ permalink raw reply
* Re: [PATCH v10 11/25] eal/pci: helpers for device name parsing/update
From: Shreyansh Jain @ 2016-10-26 6:23 UTC (permalink / raw)
To: Pattan, Reshma; +Cc: dev@dpdk.org, Thomas Monjalon, viktorin@rehivetech.com
In-Reply-To: <3AEA2BF9852C6F48A459DA490692831F010BD36E@IRSMSX109.ger.corp.intel.com>
Hello Reshma,
On Tuesday 25 October 2016 09:19 PM, Pattan, Reshma wrote:
> Hi Shreyansh,
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Shreyansh Jain
>> Sent: Friday, September 16, 2016 5:30 AM
>> To: dev@dpdk.org
>> Cc: viktorin@rehivetech.com; David Marchand <david.marchand@6wind.com>;
>> hemant.agrawal@nxp.com; Thomas Monjalon
>> <thomas.monjalon@6wind.com>; Shreyansh Jain <shreyansh.jain@nxp.com>
>> Subject: [dpdk-dev] [PATCH v10 11/25] eal/pci: helpers for device name
>> parsing/update
>>
>> From: David Marchand <david.marchand@6wind.com>
>>
>> - Move rte_eth_dev_create_unique_device_name() from ether/rte_ethdev.c to
>> common/include/rte_pci.h as rte_eal_pci_device_name(). Being a common
>> method, can be used across crypto/net PCI PMDs.
>> - Remove crypto specific routine and fallback to common name function.
>> - Introduce a eal private Update function for PCI device naming.
>>
>> Signed-off-by: David Marchand <david.marchand@6wind.com>
>> [Shreyansh: Merge crypto/pci helper patches]
>> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
>> ---
>> lib/librte_cryptodev/rte_cryptodev.c | 27 +++---------------
>> lib/librte_eal/bsdapp/eal/eal_pci.c | 49
>> +++++++++++++++++++++++++++++++++
>> lib/librte_eal/common/eal_private.h | 13 +++++++++
>> lib/librte_eal/common/include/rte_pci.h | 24 ++++++++++++++++
>> lib/librte_eal/linuxapp/eal/eal_pci.c | 13 +++++++++
>> lib/librte_ether/rte_ethdev.c | 24 +++-------------
>> 6 files changed, 107 insertions(+), 43 deletions(-)
>>
>> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
>> b/lib/librte_cryptodev/rte_cryptodev.c
>> index 2a3b649..c81e366 100644
>> --- a/lib/librte_cryptodev/rte_cryptodev.c
>> +++ b/lib/librte_cryptodev/rte_cryptodev.c
>> @@ -365,23 +365,6 @@ rte_cryptodev_pmd_allocate(const char *name, int
>> socket_id)
>> return cryptodev;
>> }
>>
>> *
>> * This function is private to EAL.
>> diff --git a/lib/librte_eal/common/include/rte_pci.h
>> b/lib/librte_eal/common/include/rte_pci.h
>> index cf81898..e1f695f 100644
>> --- a/lib/librte_eal/common/include/rte_pci.h
>> +++ b/lib/librte_eal/common/include/rte_pci.h
>> @@ -82,6 +82,7 @@ extern "C" {
>> /** Formatting string for PCI device identifier: Ex: 0000:00:01.0 */ #define
>> PCI_PRI_FMT "%.4" PRIx16 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
>> +#define PCI_PRI_STR_SIZE sizeof("XXXX:XX:XX.X")
>>
>> /** Short formatting string, without domain, for PCI device: Ex: 00:01.0 */
>> #define PCI_SHORT_PRI_FMT "%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8 @@ -308,6
>>
>> +static inline void
>> +rte_eal_pci_device_name(const struct rte_pci_addr *addr,
>> + char *output, size_t size)
>> +{
>> + RTE_VERIFY(size >= PCI_PRI_STR_SIZE);
>> + RTE_VERIFY(snprintf(output, size, PCI_PRI_FMT,
>> + addr->domain, addr->bus,
>> + addr->devid, addr->function) >= 0); }
>> +
>>
>> +int
>> +pci_update_device(const struct rte_pci_addr *addr) {
>> + char filename[PATH_MAX];
>> +
>> + snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT,
>> + pci_get_sysfs_path(), addr->domain, addr->bus, addr->devid,
>> + addr->function);
>> +
>> + return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
>> + addr->function);
>> +}
>> +
>
>
> Earlier device names were created in the format "bus:deviceid.function" as per the below ethdev API.
> Now after above new eal API the name format is "domain:bus:deviceid.func" was that intentional and why is that so.
Yes, this is intentional.
It is to bring the naming in sync with the device name being used for
scanning on the bus (/sys/bus/pci/devices/AAAA:BB:CC.D/).
Also, it was proposed in a separate patch [1] but merged in this series.
[1] http://dpdk.org/ml/archives/dev/2016-July/044614.html
(Just as a note: I am not the original author of this patch but above is
what I understood and acked it).
>
>> -static int
>> -rte_eth_dev_create_unique_device_name(char *name, size_t size,
>> - struct rte_pci_device *pci_dev)
>> -{
>> - int ret;
>> -
>> - ret = snprintf(name, size, "%d:%d.%d",
>> - pci_dev->addr.bus, pci_dev->addr.devid,
>> - pci_dev->addr.function);
>> - if (ret < 0)
>> - return ret;
>> - return 0;
>> -}
>> -
>
-
Shreyansh
^ permalink raw reply
* Re: mbuf changes
From: Alejandro Lucero @ 2016-10-26 8:28 UTC (permalink / raw)
To: Bruce Richardson; +Cc: Shreyansh Jain, dev@dpdk.org, Morten Brørup
In-Reply-To: <20161025120537.GA56680@bricha3-MOBL3.ger.corp.intel.com>
On Tue, Oct 25, 2016 at 2:05 PM, Bruce Richardson <
bruce.richardson@intel.com> wrote:
> On Tue, Oct 25, 2016 at 05:24:28PM +0530, Shreyansh Jain wrote:
> > On Monday 24 October 2016 09:55 PM, Bruce Richardson wrote:
> > > On Mon, Oct 24, 2016 at 04:11:33PM +0000, Wiles, Keith wrote:
> > > >
> > > > > On Oct 24, 2016, at 10:49 AM, Morten Brørup <
> mb@smartsharesystems.com> wrote:
> > > > >
> > > > > First of all: Thanks for a great DPDK Userspace 2016!
> > > > >
> > > > >
> > > > >
> > > > > Continuing the Userspace discussion about Olivier Matz’s proposed
> mbuf changes...
> > >
> > > Thanks for keeping the discussion going!
> > > > >
> > > > >
> > > > >
> > > > > 1.
> > > > >
> > > > > Stephen Hemminger had a noteworthy general comment about keeping
> metadata for the NIC in the appropriate section of the mbuf: Metadata
> generated by the NIC’s RX handler belongs in the first cache line, and
> metadata required by the NIC’s TX handler belongs in the second cache line.
> This also means that touching the second cache line on ingress should be
> avoided if possible; and Bruce Richardson mentioned that for this reason
> m->next was zeroed on free().
> > > > >
> > > Thinking about it, I suspect there are more fields we can reset on free
> > > to save time on alloc. Refcnt, as discussed below is one of them, but
> so
> > > too could be the nb_segs field and possibly others.
> > >
> > > > >
> > > > >
> > > > > 2.
> > > > >
> > > > > There seemed to be consensus that the size of m->refcnt should
> match the size of m->port because a packet could be duplicated on all
> physical ports for L3 multicast and L2 flooding.
> > > > >
> > > > > Furthermore, although a single physical machine (i.e. a single
> server) with 255 physical ports probably doesn’t exist, it might contain
> more than 255 virtual machines with a virtual port each, so it makes sense
> extending these mbuf fields from 8 to 16 bits.
> > > >
> > > > I thought we also talked about removing the m->port from the mbuf as
> it is not really needed.
> > > >
> > > Yes, this was mentioned, and also the option of moving the port value
> to
> > > the second cacheline, but it appears that NXP are using the port value
> > > in their NIC drivers for passing in metadata, so we'd need their
> > > agreement on any move (or removal).
> >
> > I am not sure where NXP's NIC came into picture on this, but now that it
> is
> > highlighted, this field is required for libevent implementation [1].
> >
> > A scheduler sending an event, which can be a packet, would only have
> > information of a flow_id. From this matching it back to a port, without
> > mbuf->port, would be very difficult (costly). There may be way around
> this
> > but at least in current proposal I think port would be important to have
> -
> > even if in second cache line.
> >
> > But, off the top of my head, as of now it is not being used for any
> specific
> > purpose in NXP's PMD implementation.
> >
> > Even the SoC patches don't necessarily rely on it except using it
> because it
> > is available.
> >
> > @Bruce: where did you get the NXP context here from?
> >
> Oh, I'm just mis-remembering. :-( It was someone else who was looking for
> this - Netronome, perhaps?
>
> CC'ing Alejandro in the hope I'm remembering correctly second time
> round!
>
>
Yes. Thanks Bruce!
So Netronome uses the port field and, as I commented on the user meeting,
we are happy with the field going from 8 to 16 bits.
In our case, this is something some clients have demanded, and if I'm not
wrong (I'll double check this asap), the port value is for knowing where
the packet is coming from. Think about a switch in the NIC, with ports
linked to VFs/VMs, and one or more physical ports. That port value is not
related to DPDK ports but to the switch ports. Code in the host (DPDK or
not) can receive packets from the wire or from VFs through the NIC. This is
also true for packets received by VMs, but I guess the port value is just
interested for host code.
> /Bruce
>
^ permalink raw reply
* Re: mbuf changes
From: Morten Brørup @ 2016-10-26 9:01 UTC (permalink / raw)
To: Alejandro Lucero, Bruce Richardson; +Cc: Shreyansh Jain, dev
In-Reply-To: <CAD+H9900j7LdYH79xBBO5wfHwomagLqpwqsDjuyJxozomL-dug@mail.gmail.com>
> From: Alejandro Lucero [mailto:alejandro.lucero@netronome.com]
> On Tue, Oct 25, 2016 at 2:05 PM, Bruce Richardson <bruce.richardson@intel.com> wrote:
> > On Tue, Oct 25, 2016 at 05:24:28PM +0530, Shreyansh Jain wrote:
> > > On Monday 24 October 2016 09:55 PM, Bruce Richardson wrote:
> > > > On Mon, Oct 24, 2016 at 04:11:33PM +0000, Wiles, Keith wrote:
> > > > >
> > > > > > On Oct 24, 2016, at 10:49 AM, Morten Brørup <mb@smartsharesystems.com> wrote:
> > > > > >
> > > > > > First of all: Thanks for a great DPDK Userspace 2016!
> > > > > >
> > > > > >
> > > > > >
> > > > > > Continuing the Userspace discussion about Olivier Matz’s proposed mbuf changes...
> > > >
> > > > Thanks for keeping the discussion going!
> > > > > >
> > > > > >
> > > > > >
> > > > > > 1.
> > > > > >
> > > > > > Stephen Hemminger had a noteworthy general comment about keeping metadata for the NIC in the appropriate section of the mbuf: Metadata generated by the NIC’s RX handler belongs in the first cache line, and metadata required by the NIC’s TX handler belongs in the second cache line. This also means that touching the second cache line on ingress should be avoided if possible; and Bruce Richardson mentioned that for this reason m->next was zeroed on free().
> > > > > >
> > > > Thinking about it, I suspect there are more fields we can reset on free
> > > > to save time on alloc. Refcnt, as discussed below is one of them, but so
> > > > too could be the nb_segs field and possibly others.
> > > >
> > > > > >
> > > > > >
> > > > > > 2.
> > > > > >
> > > > > > There seemed to be consensus that the size of m->refcnt should match the size of m->port because a packet could be duplicated on all physical ports for L3 multicast and L2 flooding.
> > > > > >
> > > > > > Furthermore, although a single physical machine (i.e. a single server) with 255 physical ports probably doesn’t exist, it might contain more than 255 virtual machines with a virtual port each, so it makes sense extending these mbuf fields from 8 to 16 bits.
> > > > >
> > > > > I thought we also talked about removing the m->port from the mbuf as it is not really needed.
> > > > >
> > > > Yes, this was mentioned, and also the option of moving the port value to
> > > > the second cacheline, but it appears that NXP are using the port value
> > > > in their NIC drivers for passing in metadata, so we'd need their
> > > > agreement on any move (or removal).
> > >
> > > I am not sure where NXP's NIC came into picture on this, but now that it is
> > > highlighted, this field is required for libevent implementation [1].
> > >
> > > A scheduler sending an event, which can be a packet, would only have
> > > information of a flow_id. From this matching it back to a port, without
> > > mbuf->port, would be very difficult (costly). There may be way around this
> > > but at least in current proposal I think port would be important to have -
> > > even if in second cache line.
> > >
> > > But, off the top of my head, as of now it is not being used for any specific
> > > purpose in NXP's PMD implementation.
> > >
> > > Even the SoC patches don't necessarily rely on it except using it because it
> > > is available.
> > >
> > > @Bruce: where did you get the NXP context here from?
> > >
> > Oh, I'm just mis-remembering. :-( It was someone else who was looking for
> > this - Netronome, perhaps?
> >
> > CC'ing Alejandro in the hope I'm remembering correctly second time
> > round!
> >
> Yes. Thanks Bruce!
>
> So Netronome uses the port field and, as I commented on the user meeting, we are happy with the field going from 8 to 16 bits.
>
> In our case, this is something some clients have demanded, and if I'm not wrong (I'll double check this asap), the port value is for knowing where the packet is coming from. Think about a switch in the NIC, with ports linked to VFs/VMs, and one or more physical ports. That port value is not related to DPDK ports but to the switch ports. Code in the host (DPDK or not) can receive packets from the wire or from VFs through the NIC. This is also true for packets received by VMs, but I guess the port value is just interested for host code.
Come to think of it: About ten years ago I was directly involved in the design of a silicon architecture for a stackable switch, and the packets on the backplane used a proprietary stack header which included a port number. Among other purposes, it allowed the management CPU to inject packets addressed to any physical port in the stack; and this could easily be more than 255 ports. I have seen similar proprietary headers in chips used for consumer wifi routers, allowing a single port on the CPU chip to communicate individually with the 4 LAN ports through the 5 port switch chip on the PCB. These are other examples of what Alejandro describes. So maybe this is quite common.
I think the Userspace consensus strongly supported increasing the m->port from 8 to 16 bit, so let's go for that. But do we keep port in the first cache line as is, do we fold it into the Flow Director part, or do we move it to the second cache line?
Maybe we should also consider that since m->port is widely used by the examples, it indicates that this variable is so fundamental that it is probably also widely used by real life applications. E.g. ingress filters in firewalls are quite useful (https://tools.ietf.org/html/bcp38).
-Morten
^ permalink raw reply
* Re: [PATCH v10 11/25] eal/pci: helpers for device name parsing/update
From: Pattan, Reshma @ 2016-10-26 9:12 UTC (permalink / raw)
To: Shreyansh Jain; +Cc: dev@dpdk.org, Thomas Monjalon, viktorin@rehivetech.com
In-Reply-To: <39622c65-4cbd-4841-541f-8673e1935036@nxp.com>
Hi,
> -----Original Message-----
> From: Shreyansh Jain [mailto:shreyansh.jain@nxp.com]
> Sent: Wednesday, October 26, 2016 7:23 AM
> To: Pattan, Reshma <reshma.pattan@intel.com>
> Cc: dev@dpdk.org; viktorin@rehivetech.com; David Marchand
> <david.marchand@6wind.com>; hemant.agrawal@nxp.com; Thomas Monjalon
> <thomas.monjalon@6wind.com>
> Subject: Re: [PATCH v10 11/25] eal/pci: helpers for device name parsing/update
>
> Hello Reshma,
>
> On Tuesday 25 October 2016 09:19 PM, Pattan, Reshma wrote:
> > Hi Shreyansh,
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Shreyansh Jain
> >> Sent: Friday, September 16, 2016 5:30 AM
> >> To: dev@dpdk.org
> >> Cc: viktorin@rehivetech.com; David Marchand
> >> <david.marchand@6wind.com>; hemant.agrawal@nxp.com; Thomas
> Monjalon
> >> <thomas.monjalon@6wind.com>; Shreyansh Jain <shreyansh.jain@nxp.com>
> >> Subject: [dpdk-dev] [PATCH v10 11/25] eal/pci: helpers for device
> >> name parsing/update
> >>
> >> From: David Marchand <david.marchand@6wind.com>
> >>
> >> - Move rte_eth_dev_create_unique_device_name() from ether/rte_ethdev.c
> to
> >> common/include/rte_pci.h as rte_eal_pci_device_name(). Being a common
> >> method, can be used across crypto/net PCI PMDs.
> >> - Remove crypto specific routine and fallback to common name function.
> >> - Introduce a eal private Update function for PCI device naming.
> >>
> >> Signed-off-by: David Marchand <david.marchand@6wind.com>
> >> [Shreyansh: Merge crypto/pci helper patches]
> >> Signed-off-by: Shreyansh Jain <shreyansh.jain@nxp.com>
> >> ---
> >> lib/librte_cryptodev/rte_cryptodev.c | 27 +++---------------
> >> lib/librte_eal/bsdapp/eal/eal_pci.c | 49
> >> +++++++++++++++++++++++++++++++++
> >> lib/librte_eal/common/eal_private.h | 13 +++++++++
> >> lib/librte_eal/common/include/rte_pci.h | 24 ++++++++++++++++
> >> lib/librte_eal/linuxapp/eal/eal_pci.c | 13 +++++++++
> >> lib/librte_ether/rte_ethdev.c | 24 +++-------------
> >> 6 files changed, 107 insertions(+), 43 deletions(-)
> >>
> >> diff --git a/lib/librte_cryptodev/rte_cryptodev.c
> >> b/lib/librte_cryptodev/rte_cryptodev.c
> >> index 2a3b649..c81e366 100644
> >> --- a/lib/librte_cryptodev/rte_cryptodev.c
> >> +++ b/lib/librte_cryptodev/rte_cryptodev.c
> >> @@ -365,23 +365,6 @@ rte_cryptodev_pmd_allocate(const char *name, int
> >> socket_id)
> >> return cryptodev;
> >> }
> >>
> >> *
> >> * This function is private to EAL.
> >> diff --git a/lib/librte_eal/common/include/rte_pci.h
> >> b/lib/librte_eal/common/include/rte_pci.h
> >> index cf81898..e1f695f 100644
> >> --- a/lib/librte_eal/common/include/rte_pci.h
> >> +++ b/lib/librte_eal/common/include/rte_pci.h
> >> @@ -82,6 +82,7 @@ extern "C" {
> >> /** Formatting string for PCI device identifier: Ex: 0000:00:01.0 */
> >> #define PCI_PRI_FMT "%.4" PRIx16 ":%.2" PRIx8 ":%.2" PRIx8 ".%" PRIx8
> >> +#define PCI_PRI_STR_SIZE sizeof("XXXX:XX:XX.X")
> >>
> >> /** Short formatting string, without domain, for PCI device: Ex:
> >> 00:01.0 */ #define PCI_SHORT_PRI_FMT "%.2" PRIx8 ":%.2" PRIx8 ".%"
> >> PRIx8 @@ -308,6
> >>
> >> +static inline void
> >> +rte_eal_pci_device_name(const struct rte_pci_addr *addr,
> >> + char *output, size_t size)
> >> +{
> >> + RTE_VERIFY(size >= PCI_PRI_STR_SIZE);
> >> + RTE_VERIFY(snprintf(output, size, PCI_PRI_FMT,
> >> + addr->domain, addr->bus,
> >> + addr->devid, addr->function) >= 0); }
> >> +
> >>
> >> +int
> >> +pci_update_device(const struct rte_pci_addr *addr) {
> >> + char filename[PATH_MAX];
> >> +
> >> + snprintf(filename, sizeof(filename), "%s/" PCI_PRI_FMT,
> >> + pci_get_sysfs_path(), addr->domain, addr->bus, addr->devid,
> >> + addr->function);
> >> +
> >> + return pci_scan_one(filename, addr->domain, addr->bus, addr->devid,
> >> + addr->function);
> >> +}
> >> +
> >
> >
> > Earlier device names were created in the format "bus:deviceid.function" as per
> the below ethdev API.
> > Now after above new eal API the name format is "domain:bus:deviceid.func"
> was that intentional and why is that so.
>
> Yes, this is intentional.
> It is to bring the naming in sync with the device name being used for scanning on
> the bus (/sys/bus/pci/devices/AAAA:BB:CC.D/).
Fair enough and thanks for clarification.
Thanks,
Reshma
^ permalink raw reply
* Re: DPDK & ASLR
From: Mcnamara, John @ 2016-10-26 9:13 UTC (permalink / raw)
To: Jon DeVree, dev@dpdk.org
In-Reply-To: <20161026042009.ktsazbm3qf6kbxdr@feynman.vault24.org>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jon DeVree
> Sent: Wednesday, October 26, 2016 5:20 AM
> To: dev@dpdk.org
> Subject: Re: [dpdk-dev] DPDK & ASLR
>
> On Tue, Oct 25, 2016 at 15:18:03 -0700, Samir Shah wrote:
> > Does ASLR need to be turned off system-wide, or DPDK-processes wide?
> > Could we use setarch/personality to disable ASLR for just the DPDK
> > process and leave it enabled for the rest of the system? Any
> > experience to say if that would work or not?
> >
>
> I'm using setarch/personality to disable it only in the processes using
> dpdk without any trouble.
Hi Jon,
That is interesting. Do you have some more details on how to do this.
Also, It might be worth adding this to the DPDK documentation:
http://dpdk.org/doc/guides/prog_guide/multi_proc_support.html#multi-process-limitations
John
^ permalink raw reply
* [PATCH 1/2] net/mlx5: fix link speed capability information
From: Nelio Laranjeiro @ 2016-10-26 9:44 UTC (permalink / raw)
To: dev
In-Reply-To: <cover.1477409933.git.nelio.laranjeiro@6wind.com>
Make hard-coded values dynamic to return correct link speed capabilities
(not all ConnectX-4 NICs support everything).
Fixes: e274f5732225 ("ethdev: add speed capabilities")
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
drivers/net/mlx5/mlx5.h | 1 +
drivers/net/mlx5/mlx5_ethdev.c | 25 +++++++++++++++----------
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/net/mlx5/mlx5.h b/drivers/net/mlx5/mlx5.h
index 000fb38..d7976cb 100644
--- a/drivers/net/mlx5/mlx5.h
+++ b/drivers/net/mlx5/mlx5.h
@@ -139,6 +139,7 @@ struct priv {
unsigned int reta_idx_n; /* RETA index size. */
struct fdir_filter_list *fdir_filter_list; /* Flow director rules. */
struct fdir_queue *fdir_drop_queue; /* Flow director drop queue. */
+ uint32_t link_speed_capa; /* Link speed capabilities. */
rte_spinlock_t lock; /* Lock for control functions. */
};
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index b8b3ea9..042c9bc 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -604,15 +604,7 @@ mlx5_dev_infos_get(struct rte_eth_dev *dev, struct rte_eth_dev_info *info)
info->hash_key_size = ((*priv->rss_conf) ?
(*priv->rss_conf)[0]->rss_key_len :
0);
- info->speed_capa =
- ETH_LINK_SPEED_1G |
- ETH_LINK_SPEED_10G |
- ETH_LINK_SPEED_20G |
- ETH_LINK_SPEED_25G |
- ETH_LINK_SPEED_40G |
- ETH_LINK_SPEED_50G |
- ETH_LINK_SPEED_56G |
- ETH_LINK_SPEED_100G;
+ info->speed_capa = priv->link_speed_capa;
priv_unlock(priv);
}
@@ -647,7 +639,7 @@ mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
{
struct priv *priv = mlx5_get_priv(dev);
struct ethtool_cmd edata = {
- .cmd = ETHTOOL_GSET
+ .cmd = ETHTOOL_GSET /* Deprecated since Linux v4.5. */
};
struct ifreq ifr;
struct rte_eth_link dev_link;
@@ -672,6 +664,19 @@ mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
dev_link.link_speed = 0;
else
dev_link.link_speed = link_speed;
+ priv->link_speed_capa = 0;
+ if (edata.supported & SUPPORTED_Autoneg)
+ priv->link_speed_capa |= ETH_LINK_SPEED_AUTONEG;
+ if (edata.supported & (SUPPORTED_1000baseT_Full |
+ SUPPORTED_1000baseKX_Full))
+ priv->link_speed_capa |= ETH_LINK_SPEED_1G;
+ if (edata.supported & SUPPORTED_10000baseKR_Full)
+ priv->link_speed_capa |= ETH_LINK_SPEED_10G;
+ if (edata.supported & (SUPPORTED_40000baseKR4_Full |
+ SUPPORTED_40000baseCR4_Full |
+ SUPPORTED_40000baseSR4_Full |
+ SUPPORTED_40000baseLR4_Full))
+ priv->link_speed_capa |= ETH_LINK_SPEED_40G;
dev_link.link_duplex = ((edata.duplex == DUPLEX_HALF) ?
ETH_LINK_HALF_DUPLEX : ETH_LINK_FULL_DUPLEX);
dev_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
--
2.1.4
^ permalink raw reply related
* [PATCH 2/2] net/mlx5: fix support for newer link speeds
From: Nelio Laranjeiro @ 2016-10-26 9:44 UTC (permalink / raw)
To: dev
In-Reply-To: <cover.1477409933.git.nelio.laranjeiro@6wind.com>
Not all speed capabilities can be reported properly before Linux 4.8 (25G,
50G and 100G speeds are missing), moreover the API to retrieve them only
exists since Linux 4.5, this commit thus implements compatibility code for
all versions.
Fixes: e274f5732225 ("ethdev: add speed capabilities")
Signed-off-by: Nelio Laranjeiro <nelio.laranjeiro@6wind.com>
---
drivers/net/mlx5/Makefile | 15 +++++
drivers/net/mlx5/mlx5_ethdev.c | 123 ++++++++++++++++++++++++++++++++++++++++-
2 files changed, 135 insertions(+), 3 deletions(-)
diff --git a/drivers/net/mlx5/Makefile b/drivers/net/mlx5/Makefile
index 2c13c30..cf87f0b 100644
--- a/drivers/net/mlx5/Makefile
+++ b/drivers/net/mlx5/Makefile
@@ -121,6 +121,21 @@ mlx5_autoconf.h.new: $(RTE_SDK)/scripts/auto-config-h.sh
infiniband/mlx5_hw.h \
enum MLX5_OPCODE_TSO \
$(AUTOCONF_OUTPUT)
+ $Q sh -- '$<' '$@' \
+ HAVE_ETHTOOL_LINK_MODE_25G \
+ /usr/include/linux/ethtool.h \
+ enum ETHTOOL_LINK_MODE_25000baseCR_Full_BIT \
+ $(AUTOCONF_OUTPUT)
+ $Q sh -- '$<' '$@' \
+ HAVE_ETHTOOL_LINK_MODE_50G \
+ /usr/include/linux/ethtool.h \
+ enum ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT \
+ $(AUTOCONF_OUTPUT)
+ $Q sh -- '$<' '$@' \
+ HAVE_ETHTOOL_LINK_MODE_100G \
+ /usr/include/linux/ethtool.h \
+ enum ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT \
+ $(AUTOCONF_OUTPUT)
# Create mlx5_autoconf.h or update it in case it differs from the new one.
diff --git a/drivers/net/mlx5/mlx5_ethdev.c b/drivers/net/mlx5/mlx5_ethdev.c
index 042c9bc..2d49f86 100644
--- a/drivers/net/mlx5/mlx5_ethdev.c
+++ b/drivers/net/mlx5/mlx5_ethdev.c
@@ -627,15 +627,15 @@ mlx5_dev_supported_ptypes_get(struct rte_eth_dev *dev)
}
/**
- * DPDK callback to retrieve physical link information (unlocked version).
+ * Retrieve physical link information (unlocked version using legacy ioctl).
*
* @param dev
* Pointer to Ethernet device structure.
* @param wait_to_complete
* Wait for request completion (ignored).
*/
-int
-mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
+static int
+mlx5_link_update_unlocked_gset(struct rte_eth_dev *dev, int wait_to_complete)
{
struct priv *priv = mlx5_get_priv(dev);
struct ethtool_cmd edata = {
@@ -691,6 +691,123 @@ mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
}
/**
+ * Retrieve physical link information (unlocked version using new ioctl from
+ * Linux 4.5).
+ *
+ * @param dev
+ * Pointer to Ethernet device structure.
+ * @param wait_to_complete
+ * Wait for request completion (ignored).
+ */
+static int
+mlx5_link_update_unlocked_gs(struct rte_eth_dev *dev, int wait_to_complete)
+{
+#ifdef ETHTOOL_GLINKSETTINGS
+ struct priv *priv = mlx5_get_priv(dev);
+ struct ethtool_link_settings edata = {
+ .cmd = ETHTOOL_GLINKSETTINGS,
+ };
+ struct ifreq ifr;
+ struct rte_eth_link dev_link;
+ uint64_t sc;
+
+ (void)wait_to_complete;
+ if (priv_ifreq(priv, SIOCGIFFLAGS, &ifr)) {
+ WARN("ioctl(SIOCGIFFLAGS) failed: %s", strerror(errno));
+ return -1;
+ }
+ memset(&dev_link, 0, sizeof(dev_link));
+ dev_link.link_status = ((ifr.ifr_flags & IFF_UP) &&
+ (ifr.ifr_flags & IFF_RUNNING));
+ ifr.ifr_data = (void *)&edata;
+ if (priv_ifreq(priv, SIOCETHTOOL, &ifr)) {
+ DEBUG("ioctl(SIOCETHTOOL, ETHTOOL_GLINKSETTINGS) failed: %s",
+ strerror(errno));
+ return -1;
+ }
+ dev_link.link_speed = edata.speed;
+ sc = edata.link_mode_masks[0] |
+ ((uint64_t)edata.link_mode_masks[1] << 32);
+ priv->link_speed_capa = 0;
+ /* Link speeds available in kernel v4.5. */
+ if (sc & ETHTOOL_LINK_MODE_Autoneg_BIT)
+ priv->link_speed_capa |= ETH_LINK_SPEED_AUTONEG;
+ if (sc & (ETHTOOL_LINK_MODE_1000baseT_Full_BIT |
+ ETHTOOL_LINK_MODE_1000baseKX_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_1G;
+ if (sc & (ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT |
+ ETHTOOL_LINK_MODE_10000baseKR_Full_BIT |
+ ETHTOOL_LINK_MODE_10000baseR_FEC_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_10G;
+ if (sc & (ETHTOOL_LINK_MODE_20000baseMLD2_Full_BIT |
+ ETHTOOL_LINK_MODE_20000baseKR2_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_20G;
+ if (sc & (ETHTOOL_LINK_MODE_40000baseKR4_Full_BIT |
+ ETHTOOL_LINK_MODE_40000baseCR4_Full_BIT |
+ ETHTOOL_LINK_MODE_40000baseSR4_Full_BIT |
+ ETHTOOL_LINK_MODE_40000baseLR4_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_40G;
+ if (sc & (ETHTOOL_LINK_MODE_56000baseKR4_Full_BIT |
+ ETHTOOL_LINK_MODE_56000baseCR4_Full_BIT |
+ ETHTOOL_LINK_MODE_56000baseSR4_Full_BIT |
+ ETHTOOL_LINK_MODE_56000baseLR4_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_56G;
+ /* Link speeds available in kernel v4.6. */
+#ifdef HAVE_ETHTOOL_LINK_MODE_25G
+ if (sc & (ETHTOOL_LINK_MODE_25000baseCR_Full_BIT |
+ ETHTOOL_LINK_MODE_25000baseKR_Full_BIT |
+ ETHTOOL_LINK_MODE_25000baseSR_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_25G;
+#endif
+#ifdef HAVE_ETHTOOL_LINK_MODE_50G
+ if (sc & (ETHTOOL_LINK_MODE_50000baseCR2_Full_BIT |
+ ETHTOOL_LINK_MODE_50000baseKR2_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_50G;
+#endif
+#ifdef HAVE_ETHTOOL_LINK_MODE_100G
+ if (sc & (ETHTOOL_LINK_MODE_100000baseKR4_Full_BIT |
+ ETHTOOL_LINK_MODE_100000baseSR4_Full_BIT |
+ ETHTOOL_LINK_MODE_100000baseCR4_Full_BIT |
+ ETHTOOL_LINK_MODE_100000baseLR4_ER4_Full_BIT))
+ priv->link_speed_capa |= ETH_LINK_SPEED_100G;
+#endif
+ dev_link.link_duplex = ((edata.duplex == DUPLEX_HALF) ?
+ ETH_LINK_HALF_DUPLEX : ETH_LINK_FULL_DUPLEX);
+ dev_link.link_autoneg = !(dev->data->dev_conf.link_speeds &
+ ETH_LINK_SPEED_FIXED);
+ if (memcmp(&dev_link, &dev->data->dev_link, sizeof(dev_link))) {
+ /* Link status changed. */
+ dev->data->dev_link = dev_link;
+ return 0;
+ }
+#else
+ (void)dev;
+ (void)wait_to_complete;
+#endif
+ /* Link status is still the same. */
+ return -1;
+}
+
+/**
+ * DPDK callback to retrieve physical link information (unlocked version).
+ *
+ * @param dev
+ * Pointer to Ethernet device structure.
+ * @param wait_to_complete
+ * Wait for request completion (ignored).
+ */
+int
+mlx5_link_update_unlocked(struct rte_eth_dev *dev, int wait_to_complete)
+{
+ int ret;
+
+ ret = mlx5_link_update_unlocked_gs(dev, wait_to_complete);
+ if (ret < 0)
+ ret = mlx5_link_update_unlocked_gset(dev, wait_to_complete);
+ return ret;
+}
+
+/**
* DPDK callback to retrieve physical link information.
*
* @param dev
--
2.1.4
^ permalink raw reply related
* [PATCH 0/2] mlx5: fix link speed capabilities
From: Nelio Laranjeiro @ 2016-10-26 9:44 UTC (permalink / raw)
To: dev
Make hard-coded values dynamic to return correct link speed capabilities
(not all ConnectX-4 NICs support everything).
Nelio Laranjeiro (2):
net/mlx5: fix link speed capability information
net/mlx5: fix support for newer link speeds
drivers/net/mlx5/Makefile | 15 +++++
drivers/net/mlx5/mlx5.h | 1 +
drivers/net/mlx5/mlx5_ethdev.c | 148 +++++++++++++++++++++++++++++++++++++----
3 files changed, 151 insertions(+), 13 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v2] release 16.07.1
From: Thomas Monjalon @ 2016-10-26 9:46 UTC (permalink / raw)
To: Yuanhan Liu; +Cc: dev
In-Reply-To: <1477469498-19637-1-git-send-email-yuanhan.liu@linux.intel.com>
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
A quick download button is added for the latest stable release.
Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Signed-off-by: Thomas Monjalon <thomas.monjalon@6wind.com>
---
v2:
- buttons on one row
- md5 of tarball
---
content.css | 4 ++--
download.html | 10 +++++++---
rel.html | 6 +++---
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/content.css b/content.css
index 4bd7240..4b469bd 100644
--- a/content.css
+++ b/content.css
@@ -105,11 +105,11 @@ section .button:hover {
}
section#download .button,
section#rel .button {
- width: 26%;
+ width: 18%;
}
section#download .button + .button,
section#rel .button + .button {
- margin-left: 11%;
+ margin-left: 9.3%;
}
section#events .button {
padding: 1em 3em;
diff --git a/download.html b/download.html
index 919c41e..dc5c802 100644
--- a/download.html
+++ b/download.html
@@ -41,15 +41,19 @@
<h2>Download</h2>
<a href="http://fast.dpdk.org/rel/dpdk-16.07.tar.xz" class="button">
<i class="material-icons">archive</i>
- Latest Version: 16.07
+ Latest Major<br>16.07
+ </a><!-- no whitespace
+ --><a href="http://fast.dpdk.org/rel/dpdk-16.07.1.tar.xz" class="button">
+ <i class="material-icons">archive</i>
+ Latest Stable<br>16.07.1
</a><!-- no whitespace
--><a href="/rel" class="button">
<i class="material-icons">view_list</i>
- Other Versions
+ <br>Other Versions
</a><!-- no whitespace
--><a href="/doc/quick-start" class="button">
<i class="material-icons">access_time</i>
- Quick Start Instructions
+ <br>Quick Start
</a>
<ul>
<h3>Applications</h3>
diff --git a/rel.html b/rel.html
index b95403a..ffdc513 100644
--- a/rel.html
+++ b/rel.html
@@ -59,9 +59,9 @@
<th>md5</th>
</tr>
<tr>
- <td><a href="http://fast.dpdk.org/rel/dpdk-16.07.tar.xz">DPDK 16.07</a></td>
- <td><a href="/doc/guides/rel_notes/release_16_07.html">2016 July 28</a></td>
- <td><pre>690a2bb570103e58d12f9806e8bf21be</pre></td>
+ <td><a href="http://fast.dpdk.org/rel/dpdk-16.07.1.tar.xz">DPDK 16.07.1</a></td>
+ <td><a href="/doc/guides/rel_notes/release_16_07.html">2016 October 26</a></td>
+ <td><pre>28b3831cebfa94ca533418c17de25986</pre></td>
</tr>
<tr>
<td><a href="http://fast.dpdk.org/rel/dpdk-16.04.tar.xz">DPDK 16.04</a></td>
--
2.7.0
^ permalink raw reply related
* [dpdk-announce] DPDK 16.07.1 released
From: Yuanhan Liu @ 2016-10-26 11:17 UTC (permalink / raw)
To: announce; +Cc: dpdk stable
Hi all,
Please join me in announcing the first DPDK stable release:
http://fast.dpdk.org/rel/dpdk-16.07.1.tar.xz
It includes most bug fixing patches before v16.11-rc1. Few
are missed in this release window and will be carried in
the next stable release.
Thanks.
--yliu
---
app/test-pmd/cmdline.c | 2 +-
app/test-pmd/testpmd.c | 10 +-
app/test/test_cryptodev.c | 14 +--
buildtools/pmdinfogen/pmdinfogen.c | 2 +-
doc/guides/rel_notes/release_16_07.rst | 50 +++++++++
drivers/crypto/kasumi/rte_kasumi_pmd.c | 8 +-
drivers/crypto/null/null_crypto_pmd_ops.c | 2 +-
drivers/crypto/qat/qat_adf/icp_qat_fw.h | 2 +-
drivers/crypto/snow3g/rte_snow3g_pmd.c | 8 +-
drivers/net/e1000/igb_rxtx.c | 2 +-
drivers/net/enic/base/vnic_dev.c | 36 ++++---
drivers/net/enic/enic_rxtx.c | 5 +-
drivers/net/fm10k/fm10k_ethdev.c | 5 +
drivers/net/i40e/base/i40e_common.c | 2 +-
drivers/net/i40e/i40e_ethdev.c | 37 ++++---
drivers/net/i40e/i40e_rxtx.c | 15 ++-
drivers/net/i40e/i40e_rxtx_vec.c | 16 ++-
drivers/net/ixgbe/base/ixgbe_common.c | 113 ++++++++++++---------
drivers/net/ixgbe/base/ixgbe_common.h | 1 +
drivers/net/ixgbe/base/ixgbe_vf.c | 13 +--
drivers/net/ixgbe/base/ixgbe_x550.c | 57 +++--------
drivers/net/ixgbe/base/ixgbe_x550.h | 2 -
drivers/net/ixgbe/ixgbe_ethdev.c | 12 ++-
drivers/net/ixgbe/ixgbe_rxtx_vec_common.h | 16 ++-
drivers/net/mlx4/mlx4.c | 8 +-
drivers/net/mlx5/mlx5.c | 8 +-
drivers/net/mlx5/mlx5.h | 8 +-
drivers/net/mlx5/mlx5_ethdev.c | 4 +-
drivers/net/mlx5/mlx5_fdir.c | 8 +-
drivers/net/mlx5/mlx5_mac.c | 8 +-
drivers/net/mlx5/mlx5_mr.c | 8 +-
drivers/net/mlx5/mlx5_prm.h | 4 +-
drivers/net/mlx5/mlx5_rss.c | 8 +-
drivers/net/mlx5/mlx5_rxmode.c | 8 +-
drivers/net/mlx5/mlx5_rxq.c | 8 +-
drivers/net/mlx5/mlx5_rxtx.c | 8 +-
drivers/net/mlx5/mlx5_rxtx.h | 8 +-
drivers/net/mlx5/mlx5_stats.c | 4 +-
drivers/net/mlx5/mlx5_trigger.c | 4 +-
drivers/net/mlx5/mlx5_txq.c | 8 +-
drivers/net/mlx5/mlx5_vlan.c | 4 +-
drivers/net/nfp/nfp_net.c | 4 +-
drivers/net/pcap/rte_eth_pcap.c | 4 +-
drivers/net/virtio/virtio_ethdev.c | 8 +-
drivers/net/virtio/virtio_user/virtio_user_dev.c | 112 ++++++++++++--------
drivers/net/virtio/virtio_user_ethdev.c | 42 +++++---
examples/ip_pipeline/config/diagram-generator.py | 2 +-
.../ip_pipeline/config/pipeline-to-core-mapping.py | 2 +-
examples/ip_pipeline/cpu_core_map.c | 8 ++
lib/librte_eal/bsdapp/contigmem/contigmem.c | 8 +-
lib/librte_eal/common/eal_common_pci.c | 1 +
lib/librte_eal/common/include/rte_version.h | 2 +-
lib/librte_eal/linuxapp/eal/eal_memory.c | 13 +--
lib/librte_hash/rte_cuckoo_hash.c | 12 ++-
lib/librte_mbuf/rte_mbuf.c | 8 +-
lib/librte_mempool/rte_mempool.c | 2 +-
lib/librte_sched/rte_sched.c | 18 ++--
lib/librte_table/rte_table_version.map | 3 +
lib/librte_timer/rte_timer.c | 2 +-
pkg/dpdk.spec | 2 +-
tools/dpdk-devbind.py | 11 +-
tools/dpdk-pmdinfo.py | 2 +-
62 files changed, 495 insertions(+), 317 deletions(-)
Alejandro Lucero (1):
net/nfp: fix copying MAC address
Aleksey Katargin (1):
table: fix symbol exports
Alex Zelezniak (1):
net/ixgbe: fix VF reset to apply to correct VF
Ali Volkan Atli (1):
net/e1000: fix returned number of available Rx descriptors
Arek Kusztal (1):
app/test: fix verification of digest for GCM
Beilei Xing (2):
net/i40e: fix dropping packets with ethertype 0x88A8
net/i40e: fix parsing QinQ packets type
Bruce Richardson (1):
net/mlx: fix debug build with gcc 6.1
Christian Ehrhardt (1):
examples/ip_pipeline: fix Python interpreter
Deepak Kumar Jain (2):
crypto/null: fix key size increment value
crypto/qat: fix FreeBSD build
Dror Birkman (1):
net/pcap: fix memory leak in jumbo frames
Ferruh Yigit (2):
app/testpmd: fix help of MTU set commmand
pmdinfogen: fix clang build
Gary Mussar (1):
tools: fix virtio interface name when binding
Gowrishankar Muthukrishnan (1):
examples/ip_pipeline: fix lcore mapping for ppc64
Hiroyuki Mikita (1):
sched: fix releasing enqueued packets
James Poole (1):
app/testpmd: fix timeout in Rx queue flushing
Jianfeng Tan (3):
net/virtio_user: fix first queue pair without multiqueue
net/virtio_user: fix wrong sequence of messages
net/virtio_user: fix error management during init
Jim Harris (1):
contigmem: zero all pages during mmap
John Daley (1):
net/enic: fix bad L4 checksum flag on ICMP packets
Karmarkar Suyash (1):
timer: fix lag delay
Maciej Czekaj (1):
mem: fix crash on hugepage mapping error
Nelson Escobar (1):
net/enic: fix freeing memory for descriptor ring
Olivier Matz (4):
app/testpmd: fix crash when mempool allocation fails
tools: fix json output of pmdinfo
mbuf: fix error handling on pool creation
mem: fix build with -O1
Pablo de Lara (3):
hash: fix ring size
hash: fix false zero signature key hit lookup
crypto: fix build with icc
Qi Zhang (1):
net/i40e/base: fix UDP packet header
Rich Lane (1):
net/i40e: fix null pointer dereferences when using VMDq+RSS
Weiliang Luo (1):
mempool: fix corruption due to invalid handler
Xiao Wang (5):
net/fm10k: fix MAC address removal from switch
net/ixgbe/base: fix pointer check
net/ixgbe/base: fix check for NACK
net/ixgbe/base: fix possible corruption of shadow RAM
net/ixgbe/base: fix skipping PHY config
Yangchao Zhou (1):
pci: fix memory leak when detaching device
Yuanhan Liu (1):
version: 16.07.1
Yury Kylulin (2):
net/ixgbe: fix mbuf leak during Rx queue release
net/i40e: fix mbuf leak during Rx queue release
Zhiyong Yang (1):
net/virtio: fix xstats name
^ permalink raw reply
* Re: [PATCH] pdump: revert PCI device name conversion
From: Zhang, Roy Fan @ 2016-10-26 11:22 UTC (permalink / raw)
To: Pattan, Reshma, dev@dpdk.org
In-Reply-To: <1477413098-3121-1-git-send-email-reshma.pattan@intel.com>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Reshma Pattan
> Sent: Tuesday, October 25, 2016 5:32 PM
> To: dev@dpdk.org
> Cc: Pattan, Reshma <reshma.pattan@intel.com>
> Subject: [dpdk-dev] [PATCH] pdump: revert PCI device name conversion
>
> Earlier ethdev library created the device names in the "bus:device.func"
> format hence pdump library implemented its own conversion method for
> changing the user passed device name format "domain:bus:device.func" to
> "bus:device.func"
> for finding the port id using device name using ethdev library calls. Now after
> ethdev and eal rework http://dpdk.org/dev/patchwork/patch/15855/,
> the device names are created in the format "domain:bus:device.func", so
> pdump library conversion is not needed any more, hence removed the
> corresponding code.
>
> Signed-off-by: Reshma Pattan <reshma.pattan@intel.com>
> ---
> lib/librte_pdump/rte_pdump.c | 37 ++-----------------------------------
> 1 file changed, 2 insertions(+), 35 deletions(-)
>
> diff --git a/lib/librte_pdump/rte_pdump.c b/lib/librte_pdump/rte_pdump.c
> index ea5ccd9..504a1ce 100644
> --- a/lib/librte_pdump/rte_pdump.c
> +++ b/lib/librte_pdump/rte_pdump.c
> @@ -226,29 +226,6 @@ pdump_tx(uint8_t port __rte_unused, uint16_t qidx
> __rte_unused, }
>
> static int
> -pdump_get_dombdf(char *device_id, char *domBDF, size_t len) -{
> - int ret;
> - struct rte_pci_addr dev_addr = {0};
> -
> - /* identify if device_id is pci address or name */
> - ret = eal_parse_pci_DomBDF(device_id, &dev_addr);
> - if (ret < 0)
> - return -1;
> -
> - if (dev_addr.domain)
> - ret = snprintf(domBDF, len, "%u:%u:%u.%u",
> dev_addr.domain,
> - dev_addr.bus, dev_addr.devid,
> - dev_addr.function);
> - else
> - ret = snprintf(domBDF, len, "%u:%u.%u", dev_addr.bus,
> - dev_addr.devid,
> - dev_addr.function);
> -
> - return ret;
> -}
> -
> -static int
> pdump_regitser_rx_callbacks(uint16_t end_q, uint8_t port, uint16_t queue,
> struct rte_ring *ring, struct rte_mempool
> *mp,
> uint16_t operation)
> @@ -885,7 +862,6 @@ rte_pdump_enable_by_deviceid(char *device_id,
> uint16_t queue,
> void *filter)
> {
> int ret = 0;
> - char domBDF[DEVICE_ID_SIZE];
>
> ret = pdump_validate_ring_mp(ring, mp);
> if (ret < 0)
> @@ -894,11 +870,7 @@ rte_pdump_enable_by_deviceid(char *device_id,
> uint16_t queue,
> if (ret < 0)
> return ret;
>
> - if (pdump_get_dombdf(device_id, domBDF, sizeof(domBDF)) > 0)
> - ret = pdump_prepare_client_request(domBDF, queue, flags,
> - ENABLE, ring, mp, filter);
> - else
> - ret = pdump_prepare_client_request(device_id, queue,
> flags,
> + ret = pdump_prepare_client_request(device_id, queue, flags,
> ENABLE, ring, mp, filter);
>
> return ret;
> @@ -928,17 +900,12 @@ rte_pdump_disable_by_deviceid(char *device_id,
> uint16_t queue,
> uint32_t flags)
> {
> int ret = 0;
> - char domBDF[DEVICE_ID_SIZE];
>
> ret = pdump_validate_flags(flags);
> if (ret < 0)
> return ret;
>
> - if (pdump_get_dombdf(device_id, domBDF, sizeof(domBDF)) > 0)
> - ret = pdump_prepare_client_request(domBDF, queue, flags,
> - DISABLE, NULL, NULL, NULL);
> - else
> - ret = pdump_prepare_client_request(device_id, queue,
> flags,
> + ret = pdump_prepare_client_request(device_id, queue, flags,
> DISABLE, NULL, NULL, NULL);
>
> return ret;
> --
> 2.7.4
Acked-by: Fan Zhang <roy.fan.zhang@intel.com>
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Van Haaren, Harry @ 2016-10-26 12:11 UTC (permalink / raw)
To: Jerin Jacob, dev@dpdk.org
Cc: Vangati, Narender, thomas.monjalon@6wind.com, Eads, Gage
In-Reply-To: <20161025174904.GA18333@localhost.localdomain>
> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
>
> So far, I have received constructive feedback from Intel, NXP and Linaro folks.
> Let me know, if anyone else interested in contributing to the definition of eventdev?
>
> If there are no major issues in proposed spec, then Cavium would like work on
> implementing and up-streaming the common code(lib/librte_eventdev/) and
> an associated HW driver.(Requested minor changes of v2 will be addressed
> in next version).
Hi All,
I will propose a minor change to the rte_event struct, allowing some bits to be implementation specific. Currently the rte_event struct has no space to allow an implementation store any metadata about the event. For software performance it would be really helpful if there are some bits available for the implementation to keep some flags about each event.
I suggest to rework the struct as below which opens 6 bits that were otherwise wasted, and define them as implementation specific. By implementation specific it is understood that the implementation can overwrite any information stored in those bits, and the application must not expect the data to remain after the event is scheduled.
OLD:
struct rte_event {
uint32_t flow_id:24;
uint32_t queue_id:8;
uint8_t sched_type; /* Note only 2 bits of 8 are required */
NEW:
struct rte_event {
uint32_t flow_id:24;
uint32_t sched_type:2; /* reduced size : but 2 bits is enough for the enqueue types Ordered,Atomic,Parallel.*/
uint32_t implementation:6; /* available for implementation specific metadata */
uint8_t queue_id; /* still 8 bits as before */
Thoughts? -Harry
^ permalink raw reply
* Re: [RFC] [PATCH v2] libeventdev: event driven programming model framework for DPDK
From: Jerin Jacob @ 2016-10-26 12:24 UTC (permalink / raw)
To: Van Haaren, Harry
Cc: Vangati, Narender, dev@dpdk.org, Eads, Gage,
thomas.monjalon@6wind.com
In-Reply-To: <E923DB57A917B54B9182A2E928D00FA6129AD56F@IRSMSX102.ger.corp.intel.com>
On Wed, Oct 26, 2016 at 12:11:03PM +0000, Van Haaren, Harry wrote:
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Jerin Jacob
> >
> > So far, I have received constructive feedback from Intel, NXP and Linaro folks.
> > Let me know, if anyone else interested in contributing to the definition of eventdev?
> >
> > If there are no major issues in proposed spec, then Cavium would like work on
> > implementing and up-streaming the common code(lib/librte_eventdev/) and
> > an associated HW driver.(Requested minor changes of v2 will be addressed
> > in next version).
>
> Hi All,
>
> I will propose a minor change to the rte_event struct, allowing some bits to be implementation specific. Currently the rte_event struct has no space to allow an implementation store any metadata about the event. For software performance it would be really helpful if there are some bits available for the implementation to keep some flags about each event.
OK.
>
> I suggest to rework the struct as below which opens 6 bits that were otherwise wasted, and define them as implementation specific. By implementation specific it is understood that the implementation can overwrite any information stored in those bits, and the application must not expect the data to remain after the event is scheduled.
>
> OLD:
> struct rte_event {
> uint32_t flow_id:24;
> uint32_t queue_id:8;
> uint8_t sched_type; /* Note only 2 bits of 8 are required */
>
> NEW:
> struct rte_event {
> uint32_t flow_id:24;
> uint32_t sched_type:2; /* reduced size : but 2 bits is enough for the enqueue types Ordered,Atomic,Parallel.*/
> uint32_t implementation:6; /* available for implementation specific metadata */
> uint8_t queue_id; /* still 8 bits as before */
>
>
> Thoughts? -Harry
Looks good to me. I will add it in v3.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox