[dpdk-dev] [PATCH 1/6] cxgbe: Optimize forwarding performance for 40G
On Monday, October 10/05/15, 2015 at 20:37:31 +0530, Rahul Lakkireddy wrote: > On Monday, October 10/05/15, 2015 at 07:09:27 -0700, Ananyev, Konstantin > wrote: > > Hi Rahul, > > [...] > > > > > > This additional check seems redundant for single segment > > > > > packets since rte_pktmbuf_free_seg also performs > > > > > rte_mbuf_sanity_check. > > > > > > > > > > Several PMDs already prefer to use rte_pktmbuf_free_seg directly over > > > > > rte_pktmbuf_free as it is faster. > > > > > > > > Other PMDs use rte_pktmbuf_free_seg() as each TD has an associated > > > > with it segment. So as HW is done with the TD, SW frees associated > > > > segment. > > > > In your case I don't see any point in re-implementing > > > > rte_pktmbuf_free() manually, > > > > and I don't think it would be any faster. > > > > > > > > Konstantin > > > > > > As I mentioned below, I am clearly seeing a difference of 1 Mpps. And 1 > > > Mpps is not a small difference IMHO. > > > > Agree with you here - it is a significant difference. > > > > > > > > When running l3fwd with 8 queues, I also collected a perf report. > > > When using rte_pktmbuf_free, I see that it eats up around 6% cpu as > > > below in perf top report:- > > > > > > 32.00% l3fwd[.] cxgbe_poll > > > 22.25% l3fwd[.] t4_eth_xmit > > > 20.30% l3fwd[.] main_loop > > > 6.77% l3fwd[.] rte_pktmbuf_free > > > 4.86% l3fwd[.] refill_fl_usembufs > > > 2.00% l3fwd[.] write_sgl > > > . > > > > > > > > > While, when using rte_pktmbuf_free_seg directly, I don't see above > > > problem. perf top report now comes as:- > > > --- > > > 33.36% l3fwd[.] cxgbe_poll > > > 32.69% l3fwd[.] t4_eth_xmit > > > 19.05% l3fwd[.] main_loop > > > 5.21% l3fwd[.] refill_fl_usembufs > > > 2.40% l3fwd[.] write_sgl > > > > > > --- > > > > I don't think these 6% disappeared anywhere. > > As I can see, now t4_eth_xmit() increased by roughly same amount > > (you still have same job to do). > > Right. > > > To me it looks like in that case compiler didn't really inline > > rte_pktmbuf_free(). > > Wonder can you add 'always_inline' attribute to the rte_pktmbuf_free(), > > and see would it make any difference? > > > > Konstantin > > I will try out above and update further. > Tried always_inline and didn't see any difference in performance in RHEL 6.4 with gcc 4.4.7, but was seeing 1 MPPS improvement with the above block. I've moved to latest RHEL 7.1 with gcc 4.8.3 and tried both always_inline and the above block and I'm not seeing any difference for both. Will drop this block and submit a v2. Thanks for the review Aaron and Konstantin. Thanks, Rahul
[dpdk-dev] Mellanox PMD failure w/DPDK-2.1.0 and MLNX_OFED-3.1-1.0.3
Hello I wonder if anyone can suggest why previously working dpdk code may fail in the Mellanox pmd code in dpdk-2.1.0, seemingly due to failure to create a "resource domain" via ibv_exp_create_res_domain(). I must admit I haven't seen that verb before, and it appears to be returning null with no error message. The DPDK log gives these hints: PMD: librte_pmd_mlx4: 0xa4fc20: TX queues number update: 0 -> 1 PMD: librte_pmd_mlx4: 0xa4fc20: RX queues number update: 0 -> 1 PMD: librte_pmd_mlx4: 0xa4fc20: RD creation failure: Cannot allocate memory I'm using dpdk-2.10.0 and MLNX_OFED_LINUX-3.1-1.0.3 on ubuntu14.04 with a connectx-3 card. thanks bill
[dpdk-dev] [PATCH 0/5] fixup ip pipeline examples
Hi, 2015-09-09 18:35, Dumitrescu, Cristian: > From: Stephen Hemminger [mailto:stephen at networkplumber.org] > > Lots of little trivial bugs/typos here. > > Let's not start users off with a bad example. > > Thanks very much for doing this work, Steve! > > I agree with most of the bug fixes here except a few, which I indicated in my > reply to each individual patch. > > Do you want to resend or do you want us to integrate the fixes in our next > patches? Whatever works best for you is fine with us. Please, what are the news about this series? In case it's already merged in another series, please advertise it. Thanks
[dpdk-dev] Question about store_return() in ~/dpdk/lib/librte_distributor/rte_distributor.c
Dear DPDK experts.
Thank you very much for your excellent efforts and contributions.
I have a question about store_return() in
~/dpdk/lib/librte_distributor/rte_distributor.c
The store_return() function adds a oldbuf packet to d-returns.mbuf[] queue.
If the queue is full and the oldbuf packet is NULL, the queue seems to lost a
packet in the queue without modifying ret_start/ret_count values.
Is the last position of the queue always empty?
Would you check it?
#define RTE_DISTRIB_MAX_RETURNS 128
#define RTE_DISTRIB_RETURNS_MASK (RTE_DISTRIB_MAX_RETURNS - 1)
/* stores a packet returned from a worker inside the returns array */
static inline void
store_return(uintptr_t oldbuf, struct rte_distributor *d,
unsigned *ret_start, unsigned *ret_count)
{
/* store returns in a circular buffer - code is branch-free. buffer ??
oldbuf? ??? */
d-returns.mbufs[(*ret_start + *ret_count)
RTE_DISTRIB_RETURNS_MASK]
= (void *)oldbuf;
*ret_start += (*ret_count == RTE_DISTRIB_RETURNS_MASK) !!(oldbuf);
*ret_count += (*ret_count != RTE_DISTRIB_RETURNS_MASK) !!(oldbuf);
}
If d-returns.mbufs[] queue is full, oldbuf replaces the first cell of the
queue (new packet overwrites the last packet in the queue).
ret_start is preserved if the queue is not full (count!=
MAX_VALUE(RTE_DISTRIB_RETURNS_MASK))
if ret_start is MAX value and oldbuf is not NULL, ret_start is incremented by 1.
ret_count is incremented by 1 if it is not MAX value and oldbuf is not NULL).
if ret_count is MAX value, ret_count is preserved.
The mbufs queue is written by oldbuf(NULL) even though when the queue is full
and the oldbuf packet is NULL (no packet insertion).
It may lost a cell in the queue.
If the last position of the queue is always empty, it may not be a problem.
Would you check it?
Thank you very much.
Sincerely Yours,
Ick-Sung Choi.
[dpdk-dev] Can the dpdk pktgen check the sequence of received packets?
Dear DPDK experts. Thank you very much for your excellent efforts and contributions. I am studying dpdk pktgen. I have a question about sequence checking for received packets in pktgen. Can the dpdk pktgen check the sequence of received TCP packets? Is there any wise way to check the sequence of UDP packets? If it is possible, would you let me know how can I use it? I will really appreciate for your precious answers and advices. Thank you very much. Sincerely Yours, Ick-Sung Choi.
[dpdk-dev] Hotplug
Hi Tetsuya ,
Thank you for your inputs .
I have thought about this API , but looks like it takes interface name as
argument ( which is a unique name from the rte_pci_dev instance) . But i am
looking to check if the device is attached based on the PCI address .
But ,I am going to test this too
Regards,
Srikanth
On Wed, Oct 7, 2015 at 4:45 PM, Tetsuya Mukawa wrote:
> On 2015/10/07 22:16, Srikanth Akula wrote:
> > Thank you for the inputs .
> >
> > I was able to solve the problem of device notification from my control
> > plane.
> >
> > I would like to know if we have any way to know if the PCI device is
> > already attached before we try to attach it ( if the device is already
> > attached pci probe will result an error ) .
> > But i want to know before hand to verify if the device is already
> attached
> > or not .
>
> Hi Srikanth,
>
> I guess below API may help you.
> (Unfortunately, I am out of office now, so I haven't checked it, but I
> guess it works.)
>
> - struct rte_eth_dev *rte_eth_dev_allocated(const char *name)
>
> If none NULL value is returned, a device has been already attached.
> If you want to check a physical NIC, above 'name' parameter will be like
> below.
>
> snprintf(name, size, "%d:%d.%d",
> pci_dev->addr.bus, pci_dev->addr.devid,
> pci_dev->addr.function);
>
> Thanks,
> Tetsuya
>
> >
> > I came with small API which can be used to check if the pci device is
> > already bound to any driver .
> >
> > +int
> > +rte_eal_pci_is_attached(const char *devargs)
> > +{
> > +struct rte_pci_device *dev = NULL;
> > +struct rte_pci_addr addr;
> > +memset(,0,sizeof(struct rte_pci_addr));
> > +
> > +if (eal_parse_pci_DomBDF(devargs, ) == 0)
> > + {
> > +TAILQ_FOREACH(dev, _device_list, next) {
> > +if (!rte_eal_compare_pci_addr(>addr, ))
> > + {
> > +if (dev->driver)
> > + {
> > +/*pci_dump_one_device(stdout,dev);*/
> > +RTE_LOG(WARNING, EAL, "Requested device "
> PCI_PRI_FMT
> > + " cannot be used\n", dev->addr.domain,
> dev->addr.bus,
> > +dev->addr.devid, dev->addr.function);
> > + return -1;
> > + }
> > + }
> > + }
> > + }
> > + return 0;
> > +}
> > +
> >
> > Could you please let me know if it is good to have such APIs
> >
> > Regards,
> > _Srikanth_
> >
> >
> > On Mon, Sep 28, 2015 at 9:44 PM, Stephen Hemminger <
> > stephen at networkplumber.org> wrote:
> >
> >> On Mon, 28 Sep 2015 21:12:50 -0700
> >> Srikanth Akula wrote:
> >>
> >>> Hello ,
> >>>
> >>> I am trying to write an application based on DPDK port hotplug feature
> .
> >> My
> >>> requirement is to get an event when a new PCI devices gets added to the
> >>> system on the go.
> >>>
> >>> Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers )
> that
> >> i
> >>> can use to get notifications when a new device gets added . I know the
> >>> alternatives such as inotify etc .
> >>>
> >>> But i am more interested to get equivalent support in dpdk drivers .
> >>>
> >>> Please let me know .
> >>>
> >>> Srikanth
> >> Implementing hotplug requires integration with the OS more than any
> >> additional
> >> DPDK support. What the Brocade vRouter does is leverage the existing
> Linux
> >> udev infrastructure to send a message to the router application which
> then
> >> initializes and sets up the new hardware. Most of the DPDK changes are
> >> upstream
> >> already and involve being able to dynamically add ports on the fly.
> >>
> >>
>
>
[dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API
2015-10-06 15:48 GMT+02:00 N?lio Laranjeiro :
> Hi Marc,
>
> On Sun, Oct 04, 2015 at 11:12:46PM +0200, Marc Sune wrote:
> >[...]
> > /**
> > + * Device supported speeds bitmap flags
> > + */
> > +#define ETH_LINK_SPEED_AUTONEG (0 << 0) /*<
> Autonegociate (all speeds) */
> > +#define ETH_LINK_SPEED_NO_AUTONEG(1 << 0) /*< Disable autoneg
> (fixed speed) */
> > +#define ETH_LINK_SPEED_10M_HD(1 << 1) /*< 10 Mbps
> half-duplex */
> > +#define ETH_LINK_SPEED_10M (1 << 2) /*< 10 Mbps full-duplex
> */
> > +#define ETH_LINK_SPEED_100M_HD (1 << 3) /*< 100 Mbps
> half-duplex */
> > +#define ETH_LINK_SPEED_100M (1 << 4) /*< 100 Mbps full-duplex
> */
> > +#define ETH_LINK_SPEED_1G(1 << 5) /*< 1 Gbps */
> > +#define ETH_LINK_SPEED_2_5G (1 << 6) /*< 2.5 Gbps */
> > +#define ETH_LINK_SPEED_5G(1 << 7) /*< 5 Gbps */
> > +#define ETH_LINK_SPEED_10G (1 << 8) /*< 10 Mbps */
> > +#define ETH_LINK_SPEED_20G (1 << 9) /*< 20 Gbps */
> > +#define ETH_LINK_SPEED_25G (1 << 10) /*< 25 Gbps */
> > +#define ETH_LINK_SPEED_40G (1 << 11) /*< 40 Gbps */
> > +#define ETH_LINK_SPEED_50G (1 << 12) /*< 50 Gbps */
> > +#define ETH_LINK_SPEED_56G (1 << 13) /*< 56 Gbps */
> > +#define ETH_LINK_SPEED_100G (1 << 14) /*< 100 Gbps */
> > +
> > +/**
> > + * Ethernet numeric link speeds in Mbps
> > + */
> > +#define ETH_SPEED_NUM_NONE 0 /*< Not defined */
> > +#define ETH_SPEED_NUM_10M10 /*< 10 Mbps */
> > +#define ETH_SPEED_NUM_100M 100/*< 100 Mbps */
> > +#define ETH_SPEED_NUM_1G 1000 /*< 1 Gbps */
> > +#define ETH_SPEED_NUM_2_5G 2500 /*< 2.5 Gbps */
> > +#define ETH_SPEED_NUM_5G 5000 /*< 5 Gbps */
> > +#define ETH_SPEED_NUM_10G1 /*< 10 Mbps */
> > +#define ETH_SPEED_NUM_20G2 /*< 20 Gbps */
> > +#define ETH_SPEED_NUM_25G25000 /*< 25 Gbps */
> > +#define ETH_SPEED_NUM_40G4 /*< 40 Gbps */
> > +#define ETH_SPEED_NUM_50G5 /*< 50 Gbps */
> > +#define ETH_SPEED_NUM_56G56000 /*< 56 Gbps */
> > +#define ETH_SPEED_NUM_100G 10 /*< 100 Gbps */
> > +
> > +/**
> > * A structure used to retrieve link-level information of an Ethernet
> port.
> > */
> > struct rte_eth_link {
> > - uint16_t link_speed; /**< ETH_LINK_SPEED_[10, 100, 1000,
> 1] */
> > - uint16_t link_duplex; /**< ETH_LINK_[HALF_DUPLEX, FULL_DUPLEX]
> */
> > - uint8_t link_status : 1; /**< 1 -> link up, 0 -> link down */
> > -}__attribute__((aligned(8))); /**< aligned for atomic64 read/write
> */
> > -
> > -#define ETH_LINK_SPEED_AUTONEG 0 /**< Auto-negotiate link speed.
> */
> > -#define ETH_LINK_SPEED_10 10 /**< 10 megabits/second. */
> > -#define ETH_LINK_SPEED_100 100 /**< 100 megabits/second. */
> > -#define ETH_LINK_SPEED_1000 1000/**< 1 gigabits/second. */
> > -#define ETH_LINK_SPEED_11 /**< 10 gigabits/second. */
> > -#define ETH_LINK_SPEED_10G 1 /**< alias of 10
> gigabits/second. */
> > -#define ETH_LINK_SPEED_20G 2 /**< 20 gigabits/second. */
> > -#define ETH_LINK_SPEED_40G 4 /**< 40 gigabits/second. */
> > + uint32_t link_speed; /**< Link speed (ETH_SPEED_NUM_) */
> > + uint16_t link_duplex; /**< 1 -> full duplex, 0 -> half duplex
> */
> > + uint8_t link_autoneg : 1; /**< 1 -> link speed has been autoneg */
> > + uint8_t link_status : 1; /**< 1 -> link up, 0 -> link down */
> > +} __attribute__((aligned(8))); /**< aligned for atomic64
> read/write */
> >[...]
>
> Pretty good. One question, why did you not merge link_duplex, autoneg,
> and status like:
>
> struct rte_eth_link {
> uint32_t link_speed;
> uint32_t link_duplex:1;
> uint32_t link_autoneg:1;
> uint32_t link_status:1;
> };
>
> is it really useful to keep a uint16_t for the duplex alone?
>
You are right, I've missed this one. Will be fixed in v6.
>
> Another point, the comment about link_duplex field should point to the
> defines you have changed i.e. ETH_LINK_HALF_DUPLEX, ETH_LINK_FULL_DUPLEX.
>
Right. Will do that as part of v6 + comments of Neil.
Marc
> Regards,
>
> --
> N?lio Laranjeiro
> 6WIND
>
[dpdk-dev] [PATCH v5 3/4] ethdev: redesign link speed config API
2015-10-05 12:59 GMT+02:00 Neil Horman :
> On Sun, Oct 04, 2015 at 11:12:46PM +0200, Marc Sune wrote:
> > This patch redesigns the API to set the link speed/s configure
> > for an ethernet port. Specifically:
> >
> > - it allows to define a set of advertised speeds for
> > auto-negociation.
> > - it allows to disable link auto-negociation (single fixed speed).
> > - default: auto-negociate all supported speeds.
> >
> > Other changes:
> >
> > * Added utility MACROs ETH_SPEED_NUM_XXX with the numeric
> > values of all supported link speeds, in Mbps.
> > * Converted link_speed to uint32_t to accomodate 100G speeds
> > (bug).
> > * Added autoneg flag in struct rte_eth_link to indicate if
> > link speed was a result of auto-negociation or was fixed
> > by configuration.
> > * Added utility function to convert numeric speeds to bitmap
> > fields.
> > * Adapted testpmd to the new link API.
> >
> > Signed-off-by: Marc Sune
> >
> > diff --git a/lib/librte_ether/rte_ethdev.c
> b/lib/librte_ether/rte_ethdev.c
> > index f593f6e..29b2960 100644
> > --- a/lib/librte_ether/rte_ethdev.c
> > +++ b/lib/librte_ether/rte_ethdev.c
> > @@ -1072,6 +1072,55 @@ rte_eth_dev_check_mq_mode(uint8_t port_id,
> uint16_t nb_rx_q, uint16_t nb_tx_q,
> > }
> >
> > int
> > +rte_eth_speed_to_bm_flag(uint32_t speed, int duplex, uint32_t *flag)
> > +{
> > + switch (speed) {
> > + case ETH_SPEED_NUM_10M:
> > + *flag = (duplex) ? ETH_LINK_SPEED_10M :
> > +
> ETH_LINK_SPEED_10M_HD;
> > + break;
> > + case ETH_SPEED_NUM_100M:
> > + *flag = (duplex) ? ETH_LINK_SPEED_100M :
> > +
> ETH_LINK_SPEED_100M_HD;
> > + break;
> > + case ETH_SPEED_NUM_1G:
> > + *flag = ETH_LINK_SPEED_1G;
> > + break;
> > + case ETH_SPEED_NUM_2_5G:
> > + *flag = ETH_LINK_SPEED_2_5G;
> > + break;
> > + case ETH_SPEED_NUM_5G:
> > + *flag = ETH_LINK_SPEED_5G;
> > + break;
> > + case ETH_SPEED_NUM_10G:
> > + *flag = ETH_LINK_SPEED_10G;
> > + break;
> > + case ETH_SPEED_NUM_20G:
> > + *flag = ETH_LINK_SPEED_20G;
> > + break;
> > + case ETH_SPEED_NUM_25G:
> > + *flag = ETH_LINK_SPEED_25G;
> > + break;
> > + case ETH_SPEED_NUM_40G:
> > + *flag = ETH_LINK_SPEED_40G;
> > + break;
> > + case ETH_SPEED_NUM_50G:
> > + *flag = ETH_LINK_SPEED_50G;
> > + break;
> > + case ETH_SPEED_NUM_56G:
> > + *flag = ETH_LINK_SPEED_56G;
> > + break;
> > + case ETH_SPEED_NUM_100G:
> > + *flag = ETH_LINK_SPEED_100G;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
> > +
>
> This nees to go in the appropriate version.map file for shared library
> building.
>
> > +int
> > rte_eth_dev_configure(uint8_t port_id, uint16_t nb_rx_q, uint16_t
> nb_tx_q,
> > const struct rte_eth_conf *dev_conf)
> > {
> > diff --git a/lib/librte_ether/rte_ethdev.h
> b/lib/librte_ether/rte_ethdev.h
> > index 951a423..bd333e4 100644
> > --- a/lib/librte_ether/rte_ethdev.h
> > +++ b/lib/librte_ether/rte_ethdev.h
> > @@ -238,26 +238,59 @@ struct rte_eth_stats {
> > };
> >
> > /**
> > + * Device supported speeds bitmap flags
> > + */
> > +#define ETH_LINK_SPEED_AUTONEG (0 << 0) /*<
> Autonegociate (all speeds) */
> > +#define ETH_LINK_SPEED_NO_AUTONEG(1 << 0) /*< Disable autoneg
> (fixed speed) */
> > +#define ETH_LINK_SPEED_10M_HD(1 << 1) /*< 10 Mbps
> half-duplex */
> > +#define ETH_LINK_SPEED_10M (1 << 2) /*< 10 Mbps full-duplex
> */
> > +#define ETH_LINK_SPEED_100M_HD (1 << 3) /*< 100 Mbps
> half-duplex */
> > +#define ETH_LINK_SPEED_100M (1 << 4) /*< 100 Mbps full-duplex
> */
> > +#define ETH_LINK_SPEED_1G(1 << 5) /*< 1 Gbps */
> > +#define ETH_LINK_SPEED_2_5G (1 << 6) /*< 2.5 Gbps */
> > +#define ETH_LINK_SPEED_5G(1 << 7) /*< 5 Gbps */
> > +#define ETH_LINK_SPEED_10G (1 << 8) /*< 10 Mbps */
> > +#define ETH_LINK_SPEED_20G (1 << 9) /*< 20 Gbps */
> > +#define ETH_LINK_SPEED_25G (1 << 10) /*< 25 Gbps */
> > +#define ETH_LINK_SPEED_40G (1 << 11) /*< 40 Gbps */
> > +#define ETH_LINK_SPEED_50G (1 << 12) /*< 50 Gbps */
> > +#define ETH_LINK_SPEED_56G (1 << 13) /*< 56 Gbps */
> > +#define ETH_LINK_SPEED_100G (1 << 14) /*< 100 Gbps */
> > +
> > +/**
> > + * Ethernet numeric link speeds in Mbps
> > + */
> > +#define ETH_SPEED_NUM_NONE 0 /*< Not defined */
> > +#define ETH_SPEED_NUM_10M10 /*< 10 Mbps */
> > +#define ETH_SPEED_NUM_100M 100/*< 100 Mbps */
> > +#define ETH_SPEED_NUM_1G 1000 /*< 1 Gbps */
> > +#define ETH_SPEED_NUM_2_5G 2500 /*< 2.5 Gbps */
> > +#define ETH_SPEED_NUM_5G 5000
[dpdk-dev] Can the dpdk pktgen check the sequence of received packets?
? Regards, ++Keith Wiles Intel Corporation On 10/7/15, 9:39 AM, "dev on behalf of ???" wrote: >Dear DPDK experts. > >Thank you very much for your excellent efforts and contributions. > >I am studying dpdk pktgen. > >I have a question about sequence checking for received packets in pktgen. > >Can the dpdk pktgen check the sequence of received TCP packets? > >Is there any wise way to check the sequence of UDP packets? > >If it is possible, would you let me know how can I use it? > >I will really appreciate for your precious answers and advices. Hi Ick-Sung Choi, I am afraid Pktgen can not do what you want currently, except you could capture the packet into a buffer and view it with wireshark or some pcap based tool. The packet rate for capture packets can be pretty small and slow. If you would like to improve Pktgen and send a patch it would be a good thing to add. Regards, ++Keith > >Thank you very much. > >Sincerely Yours, > >Ick-Sung Choi. >
[dpdk-dev] [PATCH] e1000: enable igb TSO support
2015-10-07 14:30, Thomas Monjalon: > 2015-09-30 09:02, Wang Xiao W: > > This patch enables igb TSO feature, the feature works on both PF and VF. > > The TCP segmentation offload needs to write the offload related information > > into the advanced context descriptors, which is similar to checksum offload. > > > > Signed-off-by: Wang Xiao W > > Anyone for a review? > First quick feedback: the release notes are not updated. +Wenzhuo, e1000 maintainer.
[dpdk-dev] [PATCH] e1000: enable igb TSO support
2015-09-30 09:02, Wang Xiao W: > This patch enables igb TSO feature, the feature works on both PF and VF. > The TCP segmentation offload needs to write the offload related information > into the advanced context descriptors, which is similar to checksum offload. > > Signed-off-by: Wang Xiao W Anyone for a review? First quick feedback: the release notes are not updated.
[dpdk-dev] Hotplug
Thank you for the inputs .
I was able to solve the problem of device notification from my control
plane.
I would like to know if we have any way to know if the PCI device is
already attached before we try to attach it ( if the device is already
attached pci probe will result an error ) .
But i want to know before hand to verify if the device is already attached
or not .
I came with small API which can be used to check if the pci device is
already bound to any driver .
+int
+rte_eal_pci_is_attached(const char *devargs)
+{
+struct rte_pci_device *dev = NULL;
+struct rte_pci_addr addr;
+memset(,0,sizeof(struct rte_pci_addr));
+
+if (eal_parse_pci_DomBDF(devargs, ) == 0)
+ {
+TAILQ_FOREACH(dev, _device_list, next) {
+if (!rte_eal_compare_pci_addr(>addr, ))
+ {
+if (dev->driver)
+ {
+/*pci_dump_one_device(stdout,dev);*/
+RTE_LOG(WARNING, EAL, "Requested device " PCI_PRI_FMT
+ " cannot be used\n", dev->addr.domain, dev->addr.bus,
+dev->addr.devid, dev->addr.function);
+ return -1;
+ }
+ }
+ }
+ }
+ return 0;
+}
+
Could you please let me know if it is good to have such APIs
Regards,
_Srikanth_
On Mon, Sep 28, 2015 at 9:44 PM, Stephen Hemminger <
stephen at networkplumber.org> wrote:
> On Mon, 28 Sep 2015 21:12:50 -0700
> Srikanth Akula wrote:
>
> > Hello ,
> >
> > I am trying to write an application based on DPDK port hotplug feature .
> My
> > requirement is to get an event when a new PCI devices gets added to the
> > system on the go.
> >
> > Do we have any in-built mechanism in DPDK (UIO/e1000/vfio drivers ) that
> i
> > can use to get notifications when a new device gets added . I know the
> > alternatives such as inotify etc .
> >
> > But i am more interested to get equivalent support in dpdk drivers .
> >
> > Please let me know .
> >
> > Srikanth
>
> Implementing hotplug requires integration with the OS more than any
> additional
> DPDK support. What the Brocade vRouter does is leverage the existing Linux
> udev infrastructure to send a message to the router application which then
> initializes and sets up the new hardware. Most of the DPDK changes are
> upstream
> already and involve being able to dynamically add ports on the fly.
>
>
[dpdk-dev] [PATCH 00/28] fm10k: update shared code from ND team
2015-09-10 12:38, Wang Xiao W: > This set of shared code update patches has been tested. Applied, thanks. Some titles were fixed and some patches are squashed or reordered. Maybe it deserves an entry in the release notes. (same comment as the recent i40e update) Jing Chen, as the fm10k maintainer, your role is to check the code, the git messages *and* the documentation updates, including the release notes. Thanks for helping
[dpdk-dev] [PATCH 00/17] Enhance mlx5 with Mellanox OFED 3.1
My laboratory (an.kaist.ac.kr) had tried to build a native kernel driver for mlx4 a few months ago, and sent the full patch to the patchwork system: http://dpdk.org/dev/patchwork/patch/6128/ This driver supports only minimal RX/TX of packets, and many standard features such as VLAN are missing. The major technical difficulty was to make a memory region that is persistent even when the user process terminates. We have sent another patch for this: http://dpdk.org/dev/patchwork/patch/6127/ Nonetheless, we abandoned this approach, because the new mlx4 PMD based on OFED 3.0 performed almost same or better than our native driver with an almost complete feature set. Still, I believe that there are rooms to improve/optimize the native driver but we just do not have enough human resources for that. In background, we tried to publish a academic paper about an automated convertor from Linux NIC drivers to DPDK poll-mode drivers, but unfortunately this project is being hold back now. Regards, Joongi 2015? 10? 6? (?) ?? 5:54, Stephen Hemminger ?? ??: > On Mon, 5 Oct 2015 19:54:35 +0200 > Adrien Mazarguil wrote: > > > Mellanox OFED 3.1 [1] comes with improved APIs that Mellanox ConnectX-4 > > (mlx5) adapters can take advantage of, such as: > > > > - Separate post and doorbell operations on all queues. > > - Lightweight RX queues called Work Queues (WQs). > > - Low-level RSS indirection table and hash key configuration. > > > > This patchset enhances mlx5 with all of these for better performance and > > flexibility. Documentation is updated accordingly. > > Has anybody explored doing a driver without the dependency on OFED? > It is certainly possible. The Linux kernel drivers don't depend on it. > And dropping OFED would certainly be faster. >
[dpdk-dev] Fwd: [PATCH] em: enable flash access, tested with Intel 82577LM
---
drivers/net/e1000/base/e1000_osdep.h| 18 --
drivers/net/e1000/em_ethdev.c | 1 +
lib/librte_eal/common/include/rte_pci_dev_ids.h | 1 +
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/e1000/base/e1000_osdep.h
b/drivers/net/e1000/base/e1000_osdep.h
index d04ec73..ed08441 100644
--- a/drivers/net/e1000/base/e1000_osdep.h
+++ b/drivers/net/e1000/base/e1000_osdep.h
@@ -155,21 +155,19 @@ static inline uint32_t e1000_read_addr(volatile void*
addr)
#define E1000_WRITE_REG_IO(hw, reg, value) \
E1000_WRITE_REG(hw, reg, value)
-/*
- * Not implemented.
- */
-
#define E1000_READ_FLASH_REG(hw, reg) \
- (E1000_ACCESS_PANIC(E1000_READ_FLASH_REG, hw, reg, 0), 0)
+ rte_le_to_cpu_32(*(volatile uint32_t *)(hw->flash_address + reg))
#define E1000_READ_FLASH_REG16(hw, reg) \
- (E1000_ACCESS_PANIC(E1000_READ_FLASH_REG16, hw, reg, 0), 0)
+ rte_le_to_cpu_16(*(volatile uint16_t *)(hw->flash_address + reg))
-#define E1000_WRITE_FLASH_REG(hw, reg, value) \
- E1000_ACCESS_PANIC(E1000_WRITE_FLASH_REG, hw, reg, value)
+#define E1000_WRITE_FLASH_REG(hw, reg, value) do { \
+ *(volatile uint32_t *)(hw->flash_address + reg) =
rte_cpu_to_le_32(value); \
+} while (0)
-#define E1000_WRITE_FLASH_REG16(hw, reg, value) \
- E1000_ACCESS_PANIC(E1000_WRITE_FLASH_REG16, hw, reg, value)
+#define E1000_WRITE_FLASH_REG16(hw, reg, value) do { \
+ *(volatile uint16_t *)(hw->flash_address + reg) =
rte_cpu_to_le_16(value); \
+} while (0)
#define STATIC static
diff --git a/drivers/net/e1000/em_ethdev.c b/drivers/net/e1000/em_ethdev.c
index 912f5dd..dd82bad 100644
--- a/drivers/net/e1000/em_ethdev.c
+++ b/drivers/net/e1000/em_ethdev.c
@@ -247,6 +247,7 @@ eth_em_dev_init(struct rte_eth_dev *eth_dev)
}
hw->hw_addr = (void *)pci_dev->mem_resource[0].addr;
+ hw->flash_address = (void *)pci_dev->mem_resource[1].addr;
hw->device_id = pci_dev->id.device_id;
adapter->stopped = 0;
diff --git a/lib/librte_eal/common/include/rte_pci_dev_ids.h
b/lib/librte_eal/common/include/rte_pci_dev_ids.h
index 265e66c..071cf8a 100644
--- a/lib/librte_eal/common/include/rte_pci_dev_ids.h
+++ b/lib/librte_eal/common/include/rte_pci_dev_ids.h
@@ -304,6 +304,7 @@ RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL,
E1000_DEV_ID_82572EI)
RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82573L)
RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82574L)
RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82574LA)
+RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_PCH_M_HV_LM)
RTE_PCI_DEV_ID_DECL_EM(PCI_VENDOR_ID_INTEL, E1000_DEV_ID_82583V)
/ Physical IGB devices from e1000_hw.h
/
--
1.9.1
[dpdk-dev] [testpmd] enable lsc to avoid TX stall, TX stall happened in following sequence start show port info 0
---
app/test-pmd/testpmd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index 386bf84..45adefa 100644
--- a/app/test-pmd/testpmd.c
+++ b/app/test-pmd/testpmd.c
@@ -1779,6 +1779,7 @@ init_port_config(void)
port = [pid];
port->dev_conf.rxmode = rx_mode;
port->dev_conf.fdir_conf = fdir_conf;
+ port->dev_conf.intr_conf.lsc = 1;
if (nb_rxq > 1) {
port->dev_conf.rx_adv_conf.rss_conf.rss_key = NULL;
port->dev_conf.rx_adv_conf.rss_conf.rss_hf = rss_hf;
--
1.9.1
[dpdk-dev] Question about store_return() in ~/dpdk/lib/librte_distributor/rte_distributor.c
On Wed, Oct 07, 2015 at 06:07:23PM +0900, ??? wrote:
> Dear DPDK experts.
>
> Thank you very much for your excellent efforts and contributions.
>
> I have a question about store_return() in
> ~/dpdk/lib/librte_distributor/rte_distributor.c
>
> The store_return() function adds a oldbuf packet to d-returns.mbuf[]
> queue.
>
> If the queue is full and the oldbuf packet is NULL, the queue seems to lost a
> packet in the queue without modifying ret_start/ret_count values.
>
> Is the last position of the queue always empty?
>
> Would you check it?
>
>
> #define RTE_DISTRIB_MAX_RETURNS 128
> #define RTE_DISTRIB_RETURNS_MASK (RTE_DISTRIB_MAX_RETURNS - 1)
>
> /* stores a packet returned from a worker inside the returns array */
> static inline void
> store_return(uintptr_t oldbuf, struct rte_distributor *d,
> unsigned *ret_start, unsigned *ret_count)
> {
> /* store returns in a circular buffer - code is branch-free. buffer
> ?? oldbuf? ??? */
> d-returns.mbufs[(*ret_start + *ret_count)
> RTE_DISTRIB_RETURNS_MASK]
> = (void *)oldbuf;
> *ret_start += (*ret_count == RTE_DISTRIB_RETURNS_MASK)
> !!(oldbuf);
> *ret_count += (*ret_count != RTE_DISTRIB_RETURNS_MASK)
> !!(oldbuf);
> }
>
> If d-returns.mbufs[] queue is full, oldbuf replaces the first cell of the
> queue (new packet overwrites the last packet in the queue).
>
> ret_start is preserved if the queue is not full (count!=
> MAX_VALUE(RTE_DISTRIB_RETURNS_MASK))
> if ret_start is MAX value and oldbuf is not NULL, ret_start is incremented by
> 1.
>
> ret_count is incremented by 1 if it is not MAX value and oldbuf is not NULL).
> if ret_count is MAX value, ret_count is preserved.
>
> The mbufs queue is written by oldbuf(NULL) even though when the queue is full
> and the oldbuf packet is NULL (no packet insertion).
> It may lost a cell in the queue.
> If the last position of the queue is always empty, it may not be a problem.
>
> Would you check it?
>
> Thank you very much.
>
> Sincerely Yours,
>
> Ick-Sung Choi.
>
Hi,
yes, it can overwrite entries in that array.
When designing the library, there were two possible use cases taken into
account:
1. The user did not want to return the packets to the distributor but pass them
elsewhere from the workers when done. In this case, the overwriting did not
matter.
2. The second case is where ordering is to be preserved, and here the user does
want to pass them back to the distributor. To accomodate this, the buffer size
is made considerably bigger than the default burst size, so that anyone who
polls the ring after each burst (or even after each second burst) should again
have no issues and avoid problems with overwriting the entry.
Regards,
/Bruce
