[dpdk-dev] Queries related to Hyperthreading
hello Intel Gurus, I have some queries related to intel HT technology. I am running an intel dpdk application and trying to benchmark as well as optimize the same. As of now it is a single threaded application and would like to keep it like that for now. I am running it on an intel sandy bridge arch processor with HT on. Now to increase the performance I have disabled HT, but am still getting the same performance[ just a marginal improvement]. Now as per our understanding so far wrt HT, two Hardware threads share the same physical core. Now if we switch off HT[from bios] shouldn't just one hardware Thread get hold of the complete CPU core. The application is heavily compute oriented and as such minimal memory access or any IO operations. Appreciate any insight on this. thanks ravi "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
[dpdk-dev] Queries related to Hyperthreading
Hi Ravi The Intel HT actually has its own resources except few places like execution units and other resources in the pipeline, hence there are many factors play here for the performance of the application with and without HT feature. In simple words, even when you turned on the HT, and use only one of the HT, then the performance will be more or less be similar to the core with HT turned off. Also assume that if you are running same piece of code in both the HTs, but it doesn't have lots have contention on the common resource (you can figure out this using vTune profiling), then there will be very marginal performance difference between HT turned ON Vs OFF. Regards Kannan Babu -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ravi Kumar Iyer Sent: Tuesday, October 7, 2014 8:59 AM To: dev at dpdk.org Subject: [dpdk-dev] Queries related to Hyperthreading hello Intel Gurus, I have some queries related to intel HT technology. I am running an intel dpdk application and trying to benchmark as well as optimize the same. As of now it is a single threaded application and would like to keep it like that for now. I am running it on an intel sandy bridge arch processor with HT on. Now to increase the performance I have disabled HT, but am still getting the same performance[ just a marginal improvement]. Now as per our understanding so far wrt HT, two Hardware threads share the same physical core. Now if we switch off HT[from bios] shouldn't just one hardware Thread get hold of the complete CPU core. The application is heavily compute oriented and as such minimal memory access or any IO operations. Appreciate any insight on this. thanks ravi "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
[dpdk-dev] Queries related to Hyperthreading
Thanks Kannan, Do we have any links/docs where in we could read more about the behavior of Hyperthreads. We are executing a code which is similar to the following example: So let us we have very tight loop of code which does basic arithmetic operations[addition, subtraction]. Now the cost to complete these operations is say C clock cycles on a single core[ with HT on]. Now if we run the same code with HT off, shouldn't the instruction pipeline of this code get executed faster [ theoretical at double speed]. Thanks ravi -Original Message- From: Ramia, Kannan Babu [mailto:kannan.babu.ra...@intel.com] Sent: Tuesday, October 07, 2014 9:48 AM To: Ravi Kumar Iyer; dev at dpdk.org Subject: RE: Queries related to Hyperthreading Hi Ravi The Intel HT actually has its own resources except few places like execution units and other resources in the pipeline, hence there are many factors play here for the performance of the application with and without HT feature. In simple words, even when you turned on the HT, and use only one of the HT, then the performance will be more or less be similar to the core with HT turned off. Also assume that if you are running same piece of code in both the HTs, but it doesn't have lots have contention on the common resource (you can figure out this using vTune profiling), then there will be very marginal performance difference between HT turned ON Vs OFF. Regards Kannan Babu -Original Message- From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ravi Kumar Iyer Sent: Tuesday, October 7, 2014 8:59 AM To: dev at dpdk.org Subject: [dpdk-dev] Queries related to Hyperthreading hello Intel Gurus, I have some queries related to intel HT technology. I am running an intel dpdk application and trying to benchmark as well as optimize the same. As of now it is a single threaded application and would like to keep it like that for now. I am running it on an intel sandy bridge arch processor with HT on. Now to increase the performance I have disabled HT, but am still getting the same performance[ just a marginal improvement]. Now as per our understanding so far wrt HT, two Hardware threads share the same physical core. Now if we switch off HT[from bios] shouldn't just one hardware Thread get hold of the complete CPU core. The application is heavily compute oriented and as such minimal memory access or any IO operations. Appreciate any insight on this. thanks ravi "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
[dpdk-dev] [pcap PATCH] pcap: fix build of all-in-one shared library
Build of some of the test binaries fails when the following flags are enabled: CONFIG_RTE_LIBRTE_PMD_PCAP=y CONFIG_RTE_BUILD_SHARED_LIB=y CONFIG_RTE_BUILD_COMBINE_LIBS=y The binarieas are missing symbols from libpcap. This patch adds the missing '-lpcap' linker flag into the respective Makefiles. Signed-off-by: stepan --- app/cmdline_test/Makefile | 4 app/dump_cfg/Makefile | 4 app/test-acl/Makefile | 4 app/test/Makefile | 4 4 files changed, 16 insertions(+) diff --git a/app/cmdline_test/Makefile b/app/cmdline_test/Makefile index e9eafd2..ce44fd5 100644 --- a/app/cmdline_test/Makefile +++ b/app/cmdline_test/Makefile @@ -47,6 +47,10 @@ SRCS-y += commands.c CFLAGS += -O3 CFLAGS += $(WERROR_FLAGS) +ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) +LDFLAGS += -lpcap +endif + include $(RTE_SDK)/mk/rte.app.mk endif diff --git a/app/dump_cfg/Makefile b/app/dump_cfg/Makefile index 3257127..513ce59 100644 --- a/app/dump_cfg/Makefile +++ b/app/dump_cfg/Makefile @@ -35,6 +35,10 @@ APP = dump_cfg CFLAGS += $(WERROR_FLAGS) +ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) +LDFLAGS += -lpcap +endif + # all source are stored in SRCS-y SRCS-y := main.c diff --git a/app/test-acl/Makefile b/app/test-acl/Makefile index 43dfdcb..ea063fd 100644 --- a/app/test-acl/Makefile +++ b/app/test-acl/Makefile @@ -37,6 +37,10 @@ APP = testacl CFLAGS += $(WERROR_FLAGS) +ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) +LDFLAGS += -lpcap +endif + # all source are stored in SRCS-y SRCS-y := main.c diff --git a/app/test/Makefile b/app/test/Makefile index 6af6d76..e456140 100644 --- a/app/test/Makefile +++ b/app/test/Makefile @@ -145,6 +145,10 @@ CFLAGS_test_kni.o += -Wno-deprecated-declarations endif CFLAGS += -D_GNU_SOURCE +ifeq ($(CONFIG_RTE_LIBRTE_PMD_PCAP),y) +LDFLAGS += -lpcap +endif + # this application needs libraries first DEPDIRS-y += lib -- 1.8.4.GIT *This email and any files transmitted with are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error then please delete it and notify the sender. Do not make a copy or forward it to anyone. This footnote also confirms that this email message has been swept for the presence of computer viruses. Adaptive Mobile Security Ltd, Ferry House, 48 Lower Mount Street, Dublin 2, Ireland Directors: B. Collins, G. Maclachlan (UK), N. Grierson (UK), J. Ennis (UK), D. Summers (UK). Registered in Ireland, Company No. 370343, VAT Reg.No.IE6390343O*
[dpdk-dev] [PATCH v2] Adding the routines rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Keith Wiles
> Sent: Monday, October 06, 2014 9:26 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] Adding the routines rte_pktmbuf_alloc_bulk()
> and rte_pktmbuf_free_bulk()
>
> Minor helper routines to mirror the mempool routines and remove the code
> from applications. The ixgbe_rxtx_vec.c routine could be changed to use
> the ret_pktmbuf_alloc_bulk() routine inplace of rte_mempool_get_bulk().
>
Can we maybe remove the reference to the vector driver for this patch. I don't
believe changes there are what we want to do.
/Bruce
> Combined __rte_mbuf_raw_alloc_bulk into the rte_pktmbuf_alloc_bulk
> function.
> Fixed up the comments to state the correct return values.
>
> Signed-off-by: Keith Wiles
> ---
> lib/librte_mbuf/rte_mbuf.h | 55
> ++
> 1 file changed, 55 insertions(+)
>
> diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> index 1c6e115..337611b 100644
> --- a/lib/librte_mbuf/rte_mbuf.h
> +++ b/lib/librte_mbuf/rte_mbuf.h
> @@ -671,6 +671,44 @@ __rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
> }
>
> /**
> + * Allocate a list of mbufs from a mempool into a mbuf array.
> + *
> + * This mbuf list contains one segment per mbuf, which has a length of 0. The
> pointer
> + * to data is initialized to have some bytes of headroom in the buffer
> + * (if buffer size allows).
> + *
> + * The routine is just a simple wrapper routine to reduce code in the
> application
> and
> + * provide a cleaner API for multiple mbuf requests.
> + *
> + * @param mp
> + * The mempool from which the mbuf is allocated.
> + * @param m_list
> + * An array of mbuf pointers, cnt must be less then or equal to the size
> of the
> array.
> + * @param cnt
> + * Number of slots in the m_list array to fill.
> + * @return
> + * - cnt is returned if a successful allocation.
> + * - <0 negative number is an error code.
> + */
> +static inline int __attribute__((always_inline))
> +rte_pktmbuf_alloc_bulk(struct rte_mempool *mp, struct rte_mbuf *m_list[],
> int16_t cnt)
> +{
> + int ret;
> +
> + ret = rte_mempool_get_bulk(mp, (void **)m_list, cnt);
> + if ( ret == 0 ) {
> + ret = cnt;
> + while(cnt--) {
> +#ifdef RTE_MBUF_REFCNT
> + rte_mbuf_refcnt_set(*m_list, 1);
> +#endif /* RTE_MBUF_REFCNT */
> + rte_pktmbuf_reset(*m_list++);
> + }
> + }
> + return ret;
> +}
> +
> +/**
> * Free a segment of a packet mbuf into its original mempool.
> *
> * Free an mbuf, without parsing other segments in case of chained
> @@ -708,6 +746,23 @@ static inline void rte_pktmbuf_free(struct rte_mbuf
> *m)
> }
> }
>
> +/**
> + * Free a list of packet mbufs back into its original mempool.
> + *
> + * Free a list of mbufs by calling rte_pktmbuf_free() in a loop as a wrapper
> function.
> + *
> + * @param m_list
> + * An array of rte_mbuf pointers to be freed.
> + * @param npkts
> + * Number of packets to free in m_list.
> + */
> +static inline void __attribute__((always_inline))
> +rte_pktmbuf_free_bulk(struct rte_mbuf *m_list[], int16_t npkts)
> +{
> + while(npkts--)
> + rte_pktmbuf_free(*m_list++);
> +}
> +
> #ifdef RTE_MBUF_REFCNT
>
> /**
> --
> 2.1.0
[dpdk-dev] [PATCH v2] ADD mode 5(tlb) to link bonding pmd
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Daniel Mrzyglod
> Sent: Friday, September 26, 2014 4:41 PM
> To: dev at dpdk.org
> Subject: [dpdk-dev] [PATCH v2] ADD mode 5(tlb) to link bonding pmd
>
>
> Signed-off-by: Daniel Mrzyglod
> ---
> app/test/test_link_bonding.c | 501
> +++-
> app/test/virtual_pmd.c |6 +-
> app/test/virtual_pmd.h |7 +
> lib/librte_pmd_bond/rte_eth_bond.h | 23 ++
> lib/librte_pmd_bond/rte_eth_bond_args.c|1 +
> lib/librte_pmd_bond/rte_eth_bond_pmd.c | 161 -
> lib/librte_pmd_bond/rte_eth_bond_private.h |3 +-
> 7 files changed, 696 insertions(+), 6 deletions(-)
>
> diff --git a/app/test/test_link_bonding.c b/app/test/test_link_bonding.c
> index c4fcaf7..77f791f 100644
> --- a/app/test/test_link_bonding.c
> +++ b/app/test/test_link_bonding.c
> @@ -41,7 +41,7 @@
> #include
> #include
> #include
> -
> +#include
> #include
> #include
> #include
> @@ -3845,6 +3845,500 @@ testsuite_teardown(void)
> return remove_slaves_and_stop_bonded_device();
> }
>
> +#define NINETY_PERCENT_NUMERAL 90
> +#define ONE_HUNDRED_PERCENT_DENOMINATOR 100
> +#define ONE_HUNDRED_PERCENT_AND_TEN_NUMERAL 110
> +static int
> +test_tlb_tx_burst(void)
> +{
> + int i, burst_size, nb_tx;
> + uint64_t nb_tx2 = 0;
> + struct rte_mbuf *pkt_burst[MAX_PKT_BURST];
> + struct rte_eth_stats port_stats[32];
> + uint64_t sum_ports_opackets = 0, all_bond_opackets = 0,
> all_bond_obytes = 0;
> + uint16_t pktlen;
> +
> + TEST_ASSERT_SUCCESS(initialize_bonded_device_with_slaves
> +
> (BONDING_MODE_ADAPTIVE_TRANSMIT_LOAD_BALANCING, 1, 3, 1),
> + "Failed to initialise bonded device");
> +
> + burst_size = 20 * test_params->bonded_slave_count;
> +
> + TEST_ASSERT(burst_size < MAX_PKT_BURST,
> + "Burst size specified is greater than supported.\n");
> +
> +
> + /* Generate 40 test bursts in 2s of packets to transmit */
> + for (i = 0; i < 40; i++) {
> + /*test two types of mac src own(bonding) and others */
> + if (i % 2 == 0) {
> + initialize_eth_header(test_params->pkt_eth_hdr,
> + (struct ether_addr *)src_mac, (struct
> ether_addr *)dst_mac_0, 0, 0);
> + } else {
> + initialize_eth_header(test_params->pkt_eth_hdr,
> + (struct ether_addr *)test_params-
> >default_slave_mac,
> + (struct ether_addr *)dst_mac_0, 0, 0);
> + }
> + pktlen = initialize_udp_header(test_params->pkt_udp_hdr,
> src_port,
> + dst_port_0, 16);
> + pktlen = initialize_ipv4_header(test_params->pkt_ipv4_hdr,
> src_addr,
> + dst_addr_0, pktlen);
> + generate_packet_burst(test_params->mbuf_pool, pkt_burst,
> + test_params->pkt_eth_hdr, 0, test_params-
> >pkt_ipv4_hdr,
> + 1, test_params->pkt_udp_hdr, burst_size, 60, 1);
> + /* Send burst on bonded port */
> + nb_tx = rte_eth_tx_burst(test_params->bonded_port_id, 0,
> pkt_burst,
> + burst_size);
> + nb_tx2 += nb_tx;
> +
> + TEST_ASSERT_EQUAL(nb_tx, burst_size,
> + "number of packet not equal burst size");
> +
> + rte_delay_us(5);
> + }
> +
> +
> + /* Verify bonded port tx stats */
> + rte_eth_stats_get(test_params->bonded_port_id, &port_stats[0]);
> +
> + all_bond_opackets = port_stats[0].opackets;
> + all_bond_obytes = port_stats[0].obytes;
> +
> + TEST_ASSERT_EQUAL(port_stats[0].opackets, (uint64_t)nb_tx2,
> + "Bonded Port (%d) opackets value (%u) not as expected
> (%d)\n",
> + test_params->bonded_port_id, (unsigned
> int)port_stats[0].opackets,
> + burst_size);
> +
> +
> + /* Verify slave ports tx stats */
> + for (i = 0; i < test_params->bonded_slave_count; i++) {
> + rte_eth_stats_get(test_params->slave_port_ids[i],
> &port_stats[i]);
> + sum_ports_opackets += port_stats[i].opackets;
> + }
> +
> + TEST_ASSERT_EQUAL(sum_ports_opackets, (uint64_t)all_bond_opackets,
> + "Total packets sent by slaves is not equalto packets
> sent by
> bond interface");
> +
> + for (i = 0; i < test_params->bonded_slave_count; i++) {
> + printf("port stats:%"PRIu64"\n", port_stats[i].opackets);
> + /* distribution of packets on each slave within +/- 10% of the
> expected value. */
> + TEST_ASSERT(port_stats[i].obytes >=
> ((all_bond_obytes*NINETY_PERCENT_NUMERAL)/
> + (test_params-
> >bond
[dpdk-dev] [PATCH 2/2] Adding the routines rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
> -Original Message-
> From: Wiles, Roger Keith [mailto:keith.wiles at windriver.com]
> Sent: Monday, October 06, 2014 9:08 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
>
> Attaching to the list does not work. If you want the code let me know it is
> only about 5K in size.
>
> On Oct 6, 2014, at 2:45 PM, Wiles, Roger Keith
> wrote:
>
> >
> > On Oct 6, 2014, at 11:13 AM, Wiles, Roger Keith > windriver.com> wrote:
> >
> >>
> >> On Oct 6, 2014, at 10:54 AM, Ananyev, Konstantin >> intel.com> wrote:
> >>
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
> Sent: Monday, October 06, 2014 3:54 PM
> To: Wiles, Roger Keith (Wind River)
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
>
> On Mon, Oct 06, 2014 at 03:50:38PM +0100, Wiles, Roger Keith wrote:
> > Hi Bruce,
> >
> > Do I need to reject the for the new routines or just make sure the
> > vector driver does not get updated to use those routines?
> >
>
> The new routines are probably useful in the general case. I see no issue
> with having them in the code, so long as the vector driver is not
> modified
> to use them.
> >>>
> >>> I 'd say the same thing for non-vector RX/TX PMD code-paths too.
> >>>
> >>> BTW, are the new functions comments valid?
> >>>
> >>> + * @return
> >>> + * - 0 if the number of mbufs allocated was ok
> >>> + * - <0 is an ERROR.
> >>> + */
> >>> +static inline int __rte_mbuf_raw_alloc_bulk(
> >>>
> >>> Though, as I can see __rte_mbuf_raw_alloc_bulk() returns either:
> >>> - number of allocated mbuf (cnt)
> >>> - negative error code
> >>
> >> Let me fix up the comments.
> >>>
> >>> And:
> >>> + * @return
> >>> + * - The number of valid mbufs pointers in the m_list array.
> >>> + * - Zero if the request cnt could not be allocated.
> >>> + */
> >>> +static inline int __attribute__((always_inline))
> >>> +rte_pktmbuf_alloc_bulk(struct rte_mempool *mp, struct rte_mbuf
> >>> *m_list[], int16_t cnt)
> >>> +{
> >>> + return __rte_mbuf_raw_alloc_bulk(mp, m_list, cnt);
> >>> +}
> >>>
> >>> Shouldn't be "less than zero if the request cnt could not be allocated."?
> >>>
> >>> BTW, is there any point to have __rte_mbuf_raw_alloc_bulk() at all?
> >>> After all, as you are calling rte_pktmbuf_reset() inside it, it doesn't
> >>> look __raw__ any more.
> >>> Might be just put its content into rte_pktmbuf_alloc_bulk() and get rid
> >>> of it.
> >>>
> >> I was just following the non-bulk routine style __rte_mbuf_raw_alloc(),
> >> but I can pull that into a single routine.
> >>
> >>> Also wonder, what is the advantage of having multiple counters inside the
> >>> same loop?
> >>> i.e:
> >>> + for(i = 0; i < cnt; i++) {
> >>> + m = *m_list++;
> >>>
> >>> Why not just:
> >>>
> >>> for(i = 0; i < cnt; i++) {
> >>> m = &m_list[i];
> >>>
> >>> Same for free:
> >>> + while(npkts--)
> >>> + rte_pktmbuf_free(*m_list++);
> >>>
> >>> While not just:
> >>> for (i = 0; i < npkts; i++)
> >>>rte_pktmbuf_free(&m_list[i]);
> >>
> >> Maybe I have it wrong or the compilers are doing the right thing now, but
> >> at one point the &m_list[i] would cause the compiler to
> generate a shift or multiple of 'i' and then add it to the base of m_list. If
> that is not the case anymore then I can update the code as
> you suggested. Using the *m_list++ just adds the size of a pointer to a
> register and continues.
> >
> > I compared the clang assembler (.s file) output from an example test code I
> > wrote to see if we have any differences in the code
> using the two styles and I found no difference and the code looked the same.
> I am not a Intel assembler expert and I would suggest
> someone else determine if it generates different code. I tried to compare the
> GCC outputs and it did look the same to me.
That's was my question:
Modern compilers are able to generate a good code for a simple loop as above.
So what's the point to use 2 iterators inside the loop, when just one is enough?
Nothing wrong technically, but makes code a bit harder to follow.
Plus, in general, it is a good practise to minimise number of iterators inside
the loop, when possible.
Konstantin
> >
> > I have attached the code and output, please let me know if I did something
> > wrong, but as it stands using the original style is what I
> want to go with.
> >
> >>>
> >>> Konstantin
> >>>
>
> /Bruce
>
> > Thanks
> > ++Keith
> >
> > On Oct 6, 2014, at 3:56 AM, Richardson, Bruce > intel.com> wrote:
> >
> >>
> >>
> >>> -Original Message-
> >>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Keith Wiles
> >>> Sent: Sunday, October 05,
[dpdk-dev] [PATCH RFC] librte_reorder: new reorder library
Hi All,
I am planning to implement packet reorder library. Details are as below,
please go through them and provide the comments.
Requirement:
To reorder out of ordered packets that are received from
different cores.
Usage:
To be used along with distributor library. Next version of distributor are
planned to distribute incoming packets to all worker cores irrespective of the
flow type.
In this case to ensure in order delivery of the packets at output side reorder
library will used by the tx end.
Assumption:
All input packets will be marked with sequence number in seqn field of mbuf,
this will be the reference for reordering at the tx end.
Sequence number will be of type uint32_t. New sequence number field seqn will
be added to mbuf structure.
Design:
a)There will be reorder buffer(circular buffer) structure maintained in reorder
library to store reordered packets and other details of buffer like head to
drain the packet from, min sequence number and other details.
b)Library will provide insert and drain functions to reorder and
fetch out the reordered packets respectively.
c)Users of library should pass the packets to insert functions for reordering.
Insertion logic:
Sequence number of current packet will be used to calculate offset in reorder
buffer and write packet to the location in the reorder buffer corresponding to
offset.
Offset is calculated as difference of current
packet sequence number and sequence number associated with reorder buffer.
During sequence number wrapping or wrapping over of reorder buffer size, before
inserting the new packet we should move offset number of packets to other
buffer called overflow buffer and advance the head of reorder buffer by
"offset-reorder buffer size" and insert the new packet.
Insert function:
int rte_reorder_insert(struct rte_reorder_buffer *buffer, struct rte_mbuf
*mbuf);
Note: Other insert function is also under plan to insert burst of packets.
Reorder buffer:
struct rte_reorder_buffer {
unsigned int size; /* The size (number of entries) of the buffer.
*/
unsigned int mask; /* Mask (size - 1) of the buffer */
unsigned int head; /* Current head of buffer */
uint32_t min_seqn; /* latest sequence number associated with
buffer */
struct rte_mbuf *entries[MAX_REORDER_BUFFER_SIZE]; /* buffer to hold
reordered mbufs */
};
d)Users can fetch out the reordered packets by drain function provided by
library. Users must pass the mbuf array , drain function should fill passed
mbuff array with the reordered buffer packets.
During drain operation, overflow buffer packets will be fetched out first and
then reorder buffer.
Drain function:
int rte_reorder_drain(struct rte_reorder_buffer *buffer, struct
rte_mbuf **mbufs)
Thanks,
Reshma
--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
[dpdk-dev] Aligned RX data.
Hi , I'm trying to receive aligned packets from the wire. Meaning that for all received packets the pkt.data is always aligned to (512 -H). Looking at the pmds of ixgbe/vmxnet I see that the pmds call __rte_mbuf_raw_alloc and set the rx descriptor with a RTE_MBUF_DATA_DMA_ADDR_DEFAULT Instead of the more appropriate RTE_MBUF_DATA_DMA_ADDR. Do I need to modify each pmd I'm using to be able to receive aligned data? Or have I missed something? Thanks
[dpdk-dev] [PATCH v2 3/4] Update library build process
On Mon, Oct 06, 2014 at 01:46:07PM -0700, Matthew Hall wrote: > On Mon, Oct 06, 2014 at 11:52:34AM +0100, Sergio Gonzalez Monroy wrote: > > Remove COMBINE_LIBS option and by default build: > > - CONFIG_RTE_BUILD_SHARED_LIB=y : both individual and combined libraries > > - CONFIG_RTE_BUILD_SHARED_LIB=n : single combined library > > As previously discussed.,It would be better for backward-compatibility of > people linking against DPDK, if the static lib could come out as both a > combined library and separate individual libraries by default. > > Otherwise everybody linking against DPDK has to change their code, and it > won't be easy for them to move forward and backward against different DPDKs > before and after this change. > > Thanks, > Matthew. Hi Matthew, My understanding from previous conversations is that backward-compatibility is not being provided for the next release, as such it is unlikely that backward-compatibility for compile/linking will be provided. I don't see how this particular patch would force people to change their code, though in all likelihood they will have to as a result of ABI changes in the following release. The only difference now would be when they link their applications against a single library instead of multiple separated libraries. Thanks, Sergio
[dpdk-dev] Aligned RX data.
> -Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex Markuze > Sent: Tuesday, October 07, 2014 10:40 AM > To: dev at dpdk.org > Subject: [dpdk-dev] Aligned RX data. > > Hi , I'm trying to receive aligned packets from the wire. > Meaning that for all received packets the pkt.data is always aligned to > (512 -H). > > Looking at the pmds of ixgbe/vmxnet I see that the pmds call > __rte_mbuf_raw_alloc and set the rx descriptor with a > RTE_MBUF_DATA_DMA_ADDR_DEFAULT > Instead of the more appropriate RTE_MBUF_DATA_DMA_ADDR. > > Do I need to modify each pmd I'm using to be able to receive aligned data? Make sure that your all your mbufs are aligned by 512 and set in your config RTE_PKTMBUF_HEADROOM=512-H? > Or have I missed something? > > Thanks
[dpdk-dev] request_pull
Hi, The attached request_pull contains the DPDK Linux Getting Started Guide converted to Sphinx and modified makefiles to convert the *.rst files to *.html files. Regards, Bernard. -- Intel Shannon Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 Business address: Dromore House, East Park, Shannon, Co. Clare This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[dpdk-dev] [PATCH RFC] librte_reorder: new reorder library
On Tue, Oct 07, 2014 at 09:33:06AM +, Pattan, Reshma wrote:
> Hi All,
>
> I am planning to implement packet reorder library. Details are as below,
> please go through them and provide the comments.
>
> Requirement:
>To reorder out of ordered packets that are received from
> different cores.
>
> Usage:
> To be used along with distributor library. Next version of distributor are
> planned to distribute incoming packets to all worker cores irrespective of
> the flow type.
> In this case to ensure in order delivery of the packets at output side
> reorder library will used by the tx end.
>
> Assumption:
> All input packets will be marked with sequence number in seqn field of mbuf,
> this will be the reference for reordering at the tx end.
> Sequence number will be of type uint32_t. New sequence number field seqn will
> be added to mbuf structure.
>
> Design:
> a)There will be reorder buffer(circular buffer) structure maintained in
> reorder library to store reordered packets and other details of buffer like
> head to drain the packet from, min sequence number and other details.
>b)Library will provide insert and drain functions to reorder
> and fetch out the reordered packets respectively.
> c)Users of library should pass the packets to insert functions for reordering.
>
> Insertion logic:
> Sequence number of current packet will be used to calculate offset in reorder
> buffer and write packet to the location in the reorder buffer corresponding
> to offset.
> Offset is calculated as difference of current
> packet sequence number and sequence number associated with reorder buffer.
>
> During sequence number wrapping or wrapping over of reorder buffer size,
> before inserting the new packet we should move offset number of packets to
> other buffer called overflow buffer and advance the head of reorder buffer by
> "offset-reorder buffer size" and insert the new packet.
>
> Insert function:
> int rte_reorder_insert(struct rte_reorder_buffer *buffer, struct rte_mbuf
> *mbuf);
> Note: Other insert function is also under plan to insert burst of packets.
>
>Reorder buffer:
> struct rte_reorder_buffer {
> unsigned int size; /* The size (number of entries) of the
> buffer. */
> unsigned int mask; /* Mask (size - 1) of the buffer */
> unsigned int head; /* Current head of buffer */
> uint32_t min_seqn; /* latest sequence number associated with
> buffer */
> struct rte_mbuf *entries[MAX_REORDER_BUFFER_SIZE]; /* buffer to hold
> reordered mbufs */
> };
>
> d)Users can fetch out the reordered packets by drain function provided by
> library. Users must pass the mbuf array , drain function should fill passed
> mbuff array with the reordered buffer packets.
> During drain operation, overflow buffer packets will be fetched out first
> and then reorder buffer.
>
> Drain function:
>int rte_reorder_drain(struct rte_reorder_buffer *buffer,
> struct rte_mbuf **mbufs)
>
> Thanks,
> Reshma
>
This seems reasonable, but why not integrate it with the distributor library
rather than create a separate library for it? It seems as though the
distributor library is a pre-requisite for this libraries use anyway, as
otherwise there will not be anything to reorder
Neil
> --
> Intel Shannon Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
> Business address: Dromore House, East Park, Shannon, Co. Clare
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please contact
> the sender and delete all copies.
>
>
[dpdk-dev] request_pull
From: Iremonger, Bernard Sent: Tuesday, October 7, 2014 11:34 AM To: dev at dpdk.org Cc: Iremonger, Bernard Subject: request_pull Hi, The attached request_pull contains the DPDK Linux Getting Started Guide converted to Sphinx and modified makefiles to convert the *.rst files to *.html files. Regards, Bernard. Please ignore previous email
[dpdk-dev] [PATCH v3] Adding the routines rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
Minor helper routines to mirror the mempool routines and remove the code
from applications. Routine used to allocate and free bulk set of mbufs.
Combined __rte_mbuf_raw_alloc_bulk into the rte_pktmbuf_alloc_bulk function.
Fixed up the comments to state the correct return values.
Signed-off-by: Keith Wiles
---
lib/librte_mbuf/rte_mbuf.h | 55 ++
1 file changed, 55 insertions(+)
diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
index 1c6e115..337611b 100644
--- a/lib/librte_mbuf/rte_mbuf.h
+++ b/lib/librte_mbuf/rte_mbuf.h
@@ -671,6 +671,44 @@ __rte_pktmbuf_prefree_seg(struct rte_mbuf *m)
}
/**
+ * Allocate a list of mbufs from a mempool into a mbuf array.
+ *
+ * This mbuf list contains one segment per mbuf, which has a length of 0. The
pointer
+ * to data is initialized to have some bytes of headroom in the buffer
+ * (if buffer size allows).
+ *
+ * The routine is just a simple wrapper routine to reduce code in the
application and
+ * provide a cleaner API for multiple mbuf requests.
+ *
+ * @param mp
+ * The mempool from which the mbuf is allocated.
+ * @param m_list
+ * An array of mbuf pointers, cnt must be less then or equal to the size of
the array.
+ * @param cnt
+ * Number of slots in the m_list array to fill.
+ * @return
+ * - cnt is returned if a successful allocation.
+ * - <0 negative number is an error code.
+ */
+static inline int __attribute__((always_inline))
+rte_pktmbuf_alloc_bulk(struct rte_mempool *mp, struct rte_mbuf *m_list[],
int16_t cnt)
+{
+ int ret;
+
+ ret = rte_mempool_get_bulk(mp, (void **)m_list, cnt);
+ if ( ret == 0 ) {
+ ret = cnt;
+ while(cnt--) {
+#ifdef RTE_MBUF_REFCNT
+ rte_mbuf_refcnt_set(*m_list, 1);
+#endif /* RTE_MBUF_REFCNT */
+ rte_pktmbuf_reset(*m_list++);
+ }
+ }
+ return ret;
+}
+
+/**
* Free a segment of a packet mbuf into its original mempool.
*
* Free an mbuf, without parsing other segments in case of chained
@@ -708,6 +746,23 @@ static inline void rte_pktmbuf_free(struct rte_mbuf *m)
}
}
+/**
+ * Free a list of packet mbufs back into its original mempool.
+ *
+ * Free a list of mbufs by calling rte_pktmbuf_free() in a loop as a wrapper
function.
+ *
+ * @param m_list
+ * An array of rte_mbuf pointers to be freed.
+ * @param npkts
+ * Number of packets to free in m_list.
+ */
+static inline void __attribute__((always_inline))
+rte_pktmbuf_free_bulk(struct rte_mbuf *m_list[], int16_t npkts)
+{
+ while(npkts--)
+ rte_pktmbuf_free(*m_list++);
+}
+
#ifdef RTE_MBUF_REFCNT
/**
--
2.1.0
[dpdk-dev] [PATCH] Fix librte_pmd_ring: connect primary and secondary ring with correct port.
librte_pmd_ring provides created port and attached port.
Packet is received from attached port if packet is sent to created port.
So, packet is received from created port if packet is sent to attached port.
It must be need two rings such as "create to attach" and "attach to create".
But current implementation uses only one ring for rx/tx.
It causes incorrect result.
Fixed:
- Make ring both rx and tx
- Connect created (primary) ring and attached (secondary) ring
- Correct m->port like librte_pmd_pcap
Signed-off-by: Masaru OKI
---
lib/librte_pmd_ring/rte_eth_ring.c | 36 +++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/lib/librte_pmd_ring/rte_eth_ring.c
b/lib/librte_pmd_ring/rte_eth_ring.c
index 4f1b6ed..d926d00 100644
--- a/lib/librte_pmd_ring/rte_eth_ring.c
+++ b/lib/librte_pmd_ring/rte_eth_ring.c
@@ -54,6 +54,7 @@ struct ring_queue {
rte_atomic64_t rx_pkts;
rte_atomic64_t tx_pkts;
rte_atomic64_t err_pkts;
+ uint8_t in_port;
};
struct pmd_internals {
@@ -80,10 +81,14 @@ eth_ring_rx(void *q, struct rte_mbuf **bufs, uint16_t
nb_bufs)
struct ring_queue *r = q;
const uint16_t nb_rx = (uint16_t)rte_ring_dequeue_burst(r->rng,
ptrs, nb_bufs);
+uint16_t cnt;
if (r->rng->flags & RING_F_SC_DEQ)
r->rx_pkts.cnt += nb_rx;
else
rte_atomic64_add(&(r->rx_pkts), nb_rx);
+for (cnt = 0; cnt < nb_rx; cnt++) {
+ bufs[cnt]->port = r->in_port;
+}
return nb_rx;
}
@@ -129,6 +134,8 @@ eth_rx_queue_setup(struct rte_eth_dev *dev,uint16_t
rx_queue_id,
{
struct pmd_internals *internals = dev->data->dev_private;
dev->data->rx_queues[rx_queue_id] =
&internals->rx_ring_queues[rx_queue_id];
+ internals->rx_ring_queues[rx_queue_id].in_port = dev->data->port_id;
+
return 0;
}
@@ -319,23 +326,34 @@ eth_dev_ring_create(const char *name, const unsigned
numa_node,
/* rx and tx are so-called from point of view of first port.
* They are inverted from the point of view of second port
*/
- struct rte_ring *rxtx[RTE_PMD_RING_MAX_RX_RINGS];
+ struct rte_ring *rx[RTE_PMD_RING_MAX_RX_RINGS];
+ struct rte_ring *tx[RTE_PMD_RING_MAX_TX_RINGS];
unsigned i;
- char rng_name[RTE_RING_NAMESIZE];
+ char rng_rxname[RTE_RING_NAMESIZE];
+ char rng_txname[RTE_RING_NAMESIZE];
unsigned num_rings = RTE_MIN(RTE_PMD_RING_MAX_RX_RINGS,
RTE_PMD_RING_MAX_TX_RINGS);
for (i = 0; i < num_rings; i++) {
- snprintf(rng_name, sizeof(rng_name), "ETH_RXTX%u_%s", i, name);
- rxtx[i] = (action == DEV_CREATE) ?
- rte_ring_create(rng_name, 1024, numa_node,
- RING_F_SP_ENQ|RING_F_SC_DEQ) :
- rte_ring_lookup(rng_name);
- if (rxtx[i] == NULL)
+ snprintf(rng_rxname, sizeof(rng_rxname),
+ "ETH_RX%u_%s", i, name);
+ snprintf(rng_txname, sizeof(rng_txname),
+ "ETH_TX%u_%s", i, name);
+ rx[i] = (action == DEV_CREATE) ?
+rte_ring_create(rng_rxname, 1024, numa_node,
+RING_F_SP_ENQ|RING_F_SC_DEQ) :
+rte_ring_lookup(rng_txname);
+ if (rx[i] == NULL)
+ return -1;
+ tx[i] = (action == DEV_CREATE) ?
+rte_ring_create(rng_txname, 1024, numa_node,
+RING_F_SP_ENQ|RING_F_SC_DEQ) :
+rte_ring_lookup(rng_rxname);
+ if (tx[i] == NULL)
return -1;
}
- if (rte_eth_from_rings(name, rxtx, num_rings, rxtx, num_rings,
numa_node))
+ if (rte_eth_from_rings(name, rx, num_rings, tx, num_rings, numa_node))
return -1;
return 0;
--
1.9.1
[dpdk-dev] [PATCH 2/2] Adding the routines rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
On Oct 7, 2014, at 4:09 AM, Ananyev, Konstantin wrote:
>
>
>> -Original Message-
>> From: Wiles, Roger Keith [mailto:keith.wiles at windriver.com]
>> Sent: Monday, October 06, 2014 9:08 PM
>> To: Ananyev, Konstantin
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
>> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
>>
>> Attaching to the list does not work. If you want the code let me know it is
>> only about 5K in size.
>>
>> On Oct 6, 2014, at 2:45 PM, Wiles, Roger Keith > windriver.com> wrote:
>>
>>>
>>> On Oct 6, 2014, at 11:13 AM, Wiles, Roger Keith >> windriver.com> wrote:
>>>
On Oct 6, 2014, at 10:54 AM, Ananyev, Konstantin >>> intel.com> wrote:
>> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce Richardson
>> Sent: Monday, October 06, 2014 3:54 PM
>> To: Wiles, Roger Keith (Wind River)
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
>> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
>>
>> On Mon, Oct 06, 2014 at 03:50:38PM +0100, Wiles, Roger Keith wrote:
>>> Hi Bruce,
>>>
>>> Do I need to reject the for the new routines or just make sure the
>>> vector driver does not get updated to use those routines?
>>>
>>
>> The new routines are probably useful in the general case. I see no issue
>> with having them in the code, so long as the vector driver is not
>> modified
>> to use them.
>
> I 'd say the same thing for non-vector RX/TX PMD code-paths too.
>
> BTW, are the new functions comments valid?
>
> + * @return
> + * - 0 if the number of mbufs allocated was ok
> + * - <0 is an ERROR.
> + */
> +static inline int __rte_mbuf_raw_alloc_bulk(
>
> Though, as I can see __rte_mbuf_raw_alloc_bulk() returns either:
> - number of allocated mbuf (cnt)
> - negative error code
Let me fix up the comments.
>
> And:
> + * @return
> + * - The number of valid mbufs pointers in the m_list array.
> + * - Zero if the request cnt could not be allocated.
> + */
> +static inline int __attribute__((always_inline))
> +rte_pktmbuf_alloc_bulk(struct rte_mempool *mp, struct rte_mbuf
> *m_list[], int16_t cnt)
> +{
> + return __rte_mbuf_raw_alloc_bulk(mp, m_list, cnt);
> +}
>
> Shouldn't be "less than zero if the request cnt could not be allocated."?
>
> BTW, is there any point to have __rte_mbuf_raw_alloc_bulk() at all?
> After all, as you are calling rte_pktmbuf_reset() inside it, it doesn't
> look __raw__ any more.
> Might be just put its content into rte_pktmbuf_alloc_bulk() and get rid
> of it.
>
I was just following the non-bulk routine style __rte_mbuf_raw_alloc(),
but I can pull that into a single routine.
> Also wonder, what is the advantage of having multiple counters inside the
> same loop?
> i.e:
> + for(i = 0; i < cnt; i++) {
> + m = *m_list++;
>
> Why not just:
>
> for(i = 0; i < cnt; i++) {
> m = &m_list[i];
>
> Same for free:
> + while(npkts--)
> + rte_pktmbuf_free(*m_list++);
>
> While not just:
> for (i = 0; i < npkts; i++)
> rte_pktmbuf_free(&m_list[i]);
Maybe I have it wrong or the compilers are doing the right thing now, but
at one point the &m_list[i] would cause the compiler to
>> generate a shift or multiple of 'i' and then add it to the base of m_list.
>> If that is not the case anymore then I can update the code as
>> you suggested. Using the *m_list++ just adds the size of a pointer to a
>> register and continues.
>>>
>>> I compared the clang assembler (.s file) output from an example test code I
>>> wrote to see if we have any differences in the code
>> using the two styles and I found no difference and the code looked the same.
>> I am not a Intel assembler expert and I would suggest
>> someone else determine if it generates different code. I tried to compare
>> the GCC outputs and it did look the same to me.
>
> That's was my question:
> Modern compilers are able to generate a good code for a simple loop as above.
> So what's the point to use 2 iterators inside the loop, when just one is
> enough?
> Nothing wrong technically, but makes code a bit harder to follow.
> Plus, in general, it is a good practise to minimise number of iterators
> inside the loop, when possible.
>
> Konstantin
Hi Konstantin,
I really do not understand the concern if the code is the same, as it appears
to me the current patch is very clean and simple. Maybe you have not seen the
v2 patch and now v3 patch I sent this morning to fix Bruce?s comment suggestion.
For the case of the free routine your suggestion would require an extra
counter/variable a bit more code a ?for? loop instead
[dpdk-dev] section mismatch warnings
On Mon, Oct 06, 2014 at 06:42:04PM +, Michael Hu (NSBU) wrote: > Hi Everyone, > > When we enable kernel config CONFIG_DEBUG_SECTION_MISMATCH=y and compile DPDK > 1.7 with 3.14.17 kernel + gcc 4.8.2, we got lots of warnings like these. > Do we have plan to fix them? If so, please advise on which version. Thanks. > > > > == Build lib/librte_eal/linuxapp/kni > cut: /proc/version_signature: No such file or directory > LD > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/built-in.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o > Building modules, stage 2. > MODPOST 1 modules > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o(.data+0x20): > Section mismatch in reference from the variable igbuio_pci_driver to the > function .text:igbuio_pci_probe() > > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o(.data+0x28): > Section mismatch in reference from the variable igbuio_pci_driver to the > function .text:igbuio_pci_remove() > > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o(.data+0x130): > Section mismatch in reference from the variable dev_attr_max_vfs to the > function .text:show_max_vfs() > > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o(.data+0x138): > Section mismatch in reference from the variable dev_attr_max_vfs to the > function .text:store_max_vfs() > > CC > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.mod.o > LD [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko > INSTALL-MODULE igb_uio.ko > > LD > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/built-in.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_main.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_api.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_common.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_ethtool.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_82599.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_82598.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_x540.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_phy.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/kcompat.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_82575.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_i210.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_api.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_mac.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_manage.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_mbx.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_nvm.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_phy.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_ethtool.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_hwmon.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_main.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_debugfs.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_param.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_procfs.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_vmdq.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/kni_misc.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/kni_net.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/kni_ethtool.o > LD [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/rte_kni.o > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/rte_kni.o(.data+0x20): > Section mismatch in reference from the variable ixgbe_ethtool_ops to the > function .text:ixgbe_get_settings() > > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/rte_kni.o(.data+0x28): > Section mismatch in reference from the variable ixgbe_ethtool_ops to the > function .text:ixgbe_set_settings() > > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/rte_kni.o(.data+0x30): > Section mismatch in reference from the variable ixgbe_ethtool_ops to the > function .text:ixgbe_get_drvinfo() > > W
[dpdk-dev] Newbie question on Fortville / i40e with regards to L2 filtering
Hello all I have recently started a project that requires DPDK and the new Fortville 40G nic. I am totally new to DPDK so please excuse what might as dumb questions. Was wondering if anyone can enlighten me to the DPDK support for a number of filter types on Fortville / i40e. I have dpdk 1.7.1 compiled and a number of filter type i've tried to call up using testpmd report back "Operation not supported". I have noticed in threads that there is ongoing work to provide hardware based filtering support for fortville / i40e. Anyone know what the current state of that? Basically i am interested in L2 filtering on Fortville: filter filter mac filter vlan filter ether_type filter Regards.
[dpdk-dev] [PATCH 09/12] Remove iopl operation for IBM Power architecture
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Cyril Chemparathy
> Sent: Monday, October 06, 2014 11:04 PM
> To: Chao Zhu; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 09/12] Remove iopl operation for IBM Power
> architecture
>
> On 9/26/2014 2:36 AM, Chao Zhu wrote:
> > iopl() call is mostly for the i386 architecture. In Power architecture.
> > It doesn't exist. This patch modified rte_eal_iopl_init() and make it
> > return -1 on Power. This means rte_config.flags will not contain
> > EAL_FLG_HIGH_IOPL flag on IBM Power architecture.
>
> Since iopl() is an x86-only thing, shouldn't the code be conditional on
> defined(RTE_ARCH_X86_64) || defined(RTE_ARCH_I686) instead of below?
>
> Better still, should we maybe break out an architecture specific init
> function? This function could set iopl on x86, and possibly do other
> lowlevel init things on other architectures...
Yep, that sounds like a good way to me too.
>
> > Signed-off-by: Chao Zhu
> > ---
> > lib/librte_eal/linuxapp/eal/eal.c | 11 +++
> > 1 files changed, 11 insertions(+), 0 deletions(-)
> >
> > diff --git a/lib/librte_eal/linuxapp/eal/eal.c
> > b/lib/librte_eal/linuxapp/eal/eal.c
> > index 4869e7c..8cc1f21 100644
> > --- a/lib/librte_eal/linuxapp/eal/eal.c
> > +++ b/lib/librte_eal/linuxapp/eal/eal.c
> > @@ -50,7 +50,10 @@
> > #include
> > #include
> > #include
> > +/* Power architecture doesn't have this header file */
> > +#ifndef RTE_ARCH_PPC_64
> > #include
> > +#endif
> >
> > #include
> > #include
> > @@ -1019,11 +1022,19 @@ rte_eal_mcfg_complete(void)
> >
> > /*
> >* Request iopl privilege for all RPL, returns 0 on success
> > + *
> > + * Power architecture doesn't have iopl function, so this function
> > + * return -1 on Power architecture, because this function is only used
> > + * in rte_eal_init to add EAL_FLG_HIGH_IOPL to rte_config.flags.
> >*/
> > static int
> > rte_eal_iopl_init(void)
> > {
> > +#ifndef RTE_ARCH_PPC_64
> > return iopl(HIGHEST_RPL);
> > +#else
> > + return -1;
> > +#endif
> > }
> >
> > /* Launch threads, called at application init(). */
[dpdk-dev] [PATCH v2 00/18] Update IXGBE base code
Hi Ouyang, 2014-09-29 15:16, Ouyang Changchun: > This patch series update IXGBE base code (a.k.a. share code) from > package 2014.03.13 to package 2014.09.04 Applied You did a big work to split patches and I did another big work to split all features and to make each commit compile-able (with a minor exception). As Neil asked, some comments are missing. But I push these commits as is because base drivers are special and it's already a good improvement since the last update submission. I'm confident that the next one will be even better in comments and splitting. Thanks -- Thomas
[dpdk-dev] [PATCH 2/2] Adding the routines rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
Hi Keith,
> -Original Message-
> From: Wiles, Roger Keith [mailto:keith.wiles at windriver.com]
> Sent: Tuesday, October 07, 2014 3:22 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
>
>
> On Oct 7, 2014, at 4:09 AM, Ananyev, Konstantin intel.com> wrote:
>
> >
> >
> >> -Original Message-
> >> From: Wiles, Roger Keith [mailto:keith.wiles at windriver.com]
> >> Sent: Monday, October 06, 2014 9:08 PM
> >> To: Ananyev, Konstantin
> >> Cc: dev at dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
> >> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
> >>
> >> Attaching to the list does not work. If you want the code let me know it
> >> is only about 5K in size.
> >>
> >> On Oct 6, 2014, at 2:45 PM, Wiles, Roger Keith >> windriver.com> wrote:
> >>
> >>>
> >>> On Oct 6, 2014, at 11:13 AM, Wiles, Roger Keith >>> windriver.com> wrote:
> >>>
>
> On Oct 6, 2014, at 10:54 AM, Ananyev, Konstantin intel.com> wrote:
>
> >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
> >> Richardson
> >> Sent: Monday, October 06, 2014 3:54 PM
> >> To: Wiles, Roger Keith (Wind River)
> >> Cc: dev at dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
> >> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
> >>
> >> On Mon, Oct 06, 2014 at 03:50:38PM +0100, Wiles, Roger Keith wrote:
> >>> Hi Bruce,
> >>>
> >>> Do I need to reject the for the new routines or just make sure the
> >>> vector driver does not get updated to use those routines?
> >>>
> >>
> >> The new routines are probably useful in the general case. I see no
> >> issue
> >> with having them in the code, so long as the vector driver is not
> >> modified
> >> to use them.
> >
> > I 'd say the same thing for non-vector RX/TX PMD code-paths too.
> >
> > BTW, are the new functions comments valid?
> >
> > + * @return
> > + * - 0 if the number of mbufs allocated was ok
> > + * - <0 is an ERROR.
> > + */
> > +static inline int __rte_mbuf_raw_alloc_bulk(
> >
> > Though, as I can see __rte_mbuf_raw_alloc_bulk() returns either:
> > - number of allocated mbuf (cnt)
> > - negative error code
>
> Let me fix up the comments.
> >
> > And:
> > + * @return
> > + * - The number of valid mbufs pointers in the m_list array.
> > + * - Zero if the request cnt could not be allocated.
> > + */
> > +static inline int __attribute__((always_inline))
> > +rte_pktmbuf_alloc_bulk(struct rte_mempool *mp, struct rte_mbuf
> > *m_list[], int16_t cnt)
> > +{
> > + return __rte_mbuf_raw_alloc_bulk(mp, m_list, cnt);
> > +}
> >
> > Shouldn't be "less than zero if the request cnt could not be
> > allocated."?
> >
> > BTW, is there any point to have __rte_mbuf_raw_alloc_bulk() at all?
> > After all, as you are calling rte_pktmbuf_reset() inside it, it doesn't
> > look __raw__ any more.
> > Might be just put its content into rte_pktmbuf_alloc_bulk() and get rid
> > of it.
> >
> I was just following the non-bulk routine style __rte_mbuf_raw_alloc(),
> but I can pull that into a single routine.
>
> > Also wonder, what is the advantage of having multiple counters inside
> > the same loop?
> > i.e:
> > + for(i = 0; i < cnt; i++) {
> > + m = *m_list++;
> >
> > Why not just:
> >
> > for(i = 0; i < cnt; i++) {
> > m = &m_list[i];
> >
> > Same for free:
> > + while(npkts--)
> > + rte_pktmbuf_free(*m_list++);
> >
> > While not just:
> > for (i = 0; i < npkts; i++)
> > rte_pktmbuf_free(&m_list[i]);
>
> Maybe I have it wrong or the compilers are doing the right thing now,
> but at one point the &m_list[i] would cause the compiler
> to
> >> generate a shift or multiple of 'i' and then add it to the base of m_list.
> >> If that is not the case anymore then I can update the code as
> >> you suggested. Using the *m_list++ just adds the size of a pointer to a
> >> register and continues.
> >>>
> >>> I compared the clang assembler (.s file) output from an example test code
> >>> I wrote to see if we have any differences in the code
> >> using the two styles and I found no difference and the code looked the
> >> same. I am not a Intel assembler expert and I would
> suggest
> >> someone else determine if it generates different code. I tried to compare
> >> the GCC outputs and it did look the same to me.
> >
> > That's was my question:
> > Modern compilers are able to generate a good code for a simple loop as
> > above.
> > So what's the point to use 2 iterators inside the loop, when just one is
> > enough?
>
[dpdk-dev] Aligned RX data.
RTE_PKTMBUF_HEADROOM defines the headroom this would be true only if the buff_start was aligned to 512 which is not. On Tue, Oct 7, 2014 at 1:05 PM, Ananyev, Konstantin < konstantin.ananyev at intel.com> wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex Markuze > > Sent: Tuesday, October 07, 2014 10:40 AM > > To: dev at dpdk.org > > Subject: [dpdk-dev] Aligned RX data. > > > > Hi , I'm trying to receive aligned packets from the wire. > > Meaning that for all received packets the pkt.data is always aligned to > > (512 -H). > > > > Looking at the pmds of ixgbe/vmxnet I see that the pmds call > > __rte_mbuf_raw_alloc and set the rx descriptor with a > > RTE_MBUF_DATA_DMA_ADDR_DEFAULT > > Instead of the more appropriate RTE_MBUF_DATA_DMA_ADDR. > > > > Do I need to modify each pmd I'm using to be able to receive aligned > data? > > Make sure that your all your mbufs are aligned by 512 and set in your > config RTE_PKTMBUF_HEADROOM=512-H? > > > > Or have I missed something? > > > > Thanks >
[dpdk-dev] [PATCH 2/2] Adding the routines rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
On Oct 7, 2014, at 10:42 AM, Ananyev, Konstantin wrote:
> Hi Keith,
>
>> -Original Message-
>> From: Wiles, Roger Keith [mailto:keith.wiles at windriver.com]
>> Sent: Tuesday, October 07, 2014 3:22 PM
>> To: Ananyev, Konstantin
>> Cc: dev at dpdk.org
>> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
>> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
>>
>>
>> On Oct 7, 2014, at 4:09 AM, Ananyev, Konstantin > intel.com> wrote:
>>
>>>
>>>
-Original Message-
From: Wiles, Roger Keith [mailto:keith.wiles at windriver.com]
Sent: Monday, October 06, 2014 9:08 PM
To: Ananyev, Konstantin
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
Attaching to the list does not work. If you want the code let me know it
is only about 5K in size.
On Oct 6, 2014, at 2:45 PM, Wiles, Roger Keith >>> windriver.com> wrote:
>
> On Oct 6, 2014, at 11:13 AM, Wiles, Roger Keith windriver.com> wrote:
>
>>
>> On Oct 6, 2014, at 10:54 AM, Ananyev, Konstantin > intel.com> wrote:
>>
From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
Richardson
Sent: Monday, October 06, 2014 3:54 PM
To: Wiles, Roger Keith (Wind River)
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
On Mon, Oct 06, 2014 at 03:50:38PM +0100, Wiles, Roger Keith wrote:
> Hi Bruce,
>
> Do I need to reject the for the new routines or just make sure the
> vector driver does not get updated to use those routines?
>
The new routines are probably useful in the general case. I see no
issue
with having them in the code, so long as the vector driver is not
modified
to use them.
>>>
>>> I 'd say the same thing for non-vector RX/TX PMD code-paths too.
>>>
>>> BTW, are the new functions comments valid?
>>>
>>> + * @return
>>> + * - 0 if the number of mbufs allocated was ok
>>> + * - <0 is an ERROR.
>>> + */
>>> +static inline int __rte_mbuf_raw_alloc_bulk(
>>>
>>> Though, as I can see __rte_mbuf_raw_alloc_bulk() returns either:
>>> - number of allocated mbuf (cnt)
>>> - negative error code
>>
>> Let me fix up the comments.
>>>
>>> And:
>>> + * @return
>>> + * - The number of valid mbufs pointers in the m_list array.
>>> + * - Zero if the request cnt could not be allocated.
>>> + */
>>> +static inline int __attribute__((always_inline))
>>> +rte_pktmbuf_alloc_bulk(struct rte_mempool *mp, struct rte_mbuf
>>> *m_list[], int16_t cnt)
>>> +{
>>> + return __rte_mbuf_raw_alloc_bulk(mp, m_list, cnt);
>>> +}
>>>
>>> Shouldn't be "less than zero if the request cnt could not be
>>> allocated."?
>>>
>>> BTW, is there any point to have __rte_mbuf_raw_alloc_bulk() at all?
>>> After all, as you are calling rte_pktmbuf_reset() inside it, it doesn't
>>> look __raw__ any more.
>>> Might be just put its content into rte_pktmbuf_alloc_bulk() and get rid
>>> of it.
>>>
>> I was just following the non-bulk routine style __rte_mbuf_raw_alloc(),
>> but I can pull that into a single routine.
>>
>>> Also wonder, what is the advantage of having multiple counters inside
>>> the same loop?
>>> i.e:
>>> + for(i = 0; i < cnt; i++) {
>>> + m = *m_list++;
>>>
>>> Why not just:
>>>
>>> for(i = 0; i < cnt; i++) {
>>> m = &m_list[i];
>>>
>>> Same for free:
>>> + while(npkts--)
>>> + rte_pktmbuf_free(*m_list++);
>>>
>>> While not just:
>>> for (i = 0; i < npkts; i++)
>>> rte_pktmbuf_free(&m_list[i]);
>>
>> Maybe I have it wrong or the compilers are doing the right thing now,
>> but at one point the &m_list[i] would cause the compiler
>> to
generate a shift or multiple of 'i' and then add it to the base of m_list.
If that is not the case anymore then I can update the code as
you suggested. Using the *m_list++ just adds the size of a pointer to a
register and continues.
>
> I compared the clang assembler (.s file) output from an example test code
> I wrote to see if we have any differences in the code
using the two styles and I found no difference and the code looked the
same. I am not a Intel assembler expert and I would
>> suggest
someone else determine if it generates different code. I tried to compare
the GCC outputs and it did look the same to me.
>>>
>>> That's was my question:
>>> Modern compilers are able to generate a good code for a simple loop a
[dpdk-dev] Aligned RX data.
> -Original Message- > From: Ananyev, Konstantin > Sent: Tuesday, October 07, 2014 5:03 PM > To: Ananyev, Konstantin > Subject: FW: [dpdk-dev] Aligned RX data. > > > > From: Alex Markuze [mailto:alex at weka.io] > Sent: Tuesday, October 07, 2014 4:52 PM > To: Ananyev, Konstantin > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] Aligned RX data. > > RTE_PKTMBUF_HEADROOM defines the headroom Yes. >this would be true only if the buff_start was?aligned to 512 which is not. As I said: " Make sure that your all your mbufs are aligned by 512". Konstantin > > On Tue, Oct 7, 2014 at 1:05 PM, Ananyev, Konstantin intel.com> wrote: > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Alex Markuze > > Sent: Tuesday, October 07, 2014 10:40 AM > > To: dev at dpdk.org > > Subject: [dpdk-dev] Aligned RX data. > > > > Hi , I'm trying to receive aligned packets from the wire. > > Meaning that for all received packets the pkt.data is always aligned to > > (512 -H). > > > > Looking at the pmds of ixgbe/vmxnet I see that the pmds call > > __rte_mbuf_raw_alloc and set the rx descriptor with a > > RTE_MBUF_DATA_DMA_ADDR_DEFAULT > > Instead of the more appropriate RTE_MBUF_DATA_DMA_ADDR. > > > > Do I need to modify each pmd I'm using to be able to receive aligned data? > Make sure that your all your mbufs are aligned by 512 and set in your config > RTE_PKTMBUF_HEADROOM=512-H? > > > > Or have I missed something? > > > > Thanks
[dpdk-dev] [PATCH 00/15] i40e base driver udpate
> Here is the update of i40e base driver. Also it involves a few > relevant necessary code changes in i40e PMD. > > Helin Zhang (15): > i40e: make the indentation more consistent in share code > i40e: support nvmupdate by default > i40e: remove useless code which was written for Solaris > i40e: remove test code for 'ethtool' > i40e: force a shifted '1' to be 'unsigned' > i40e: remove useless code for pre-boot support > i40e: Get rid of sparse warnings, and remove unreachable code > i40e: remove code which is for software validation only > i40e: remove code for TPH (TLP Processing Hints) > i40e: support of 10G base T > i40e: expose debug_write_register request > i40e: workaround of get_firmware_version, and enhancements > i40e: Use get_link_status to report FC settings > i40e: fix and enhancement in arq_event_info struct > i40e: support redefined struct of 'i40e_arq_event_info' Applied Nice work, only 2 comments: - title should begin with i40e/base - last 2 patches are dependent and cannot be splitted without breaking compilation Thanks -- Thomas
[dpdk-dev] [PATCH 2/2] Adding the routines rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
> -Original Message-
> From: Wiles, Roger Keith [mailto:keith.wiles at windriver.com]
> Sent: Tuesday, October 07, 2014 4:56 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
>
>
> On Oct 7, 2014, at 10:42 AM, Ananyev, Konstantin intel.com> wrote:
>
> > Hi Keith,
> >
> >> -Original Message-
> >> From: Wiles, Roger Keith [mailto:keith.wiles at windriver.com]
> >> Sent: Tuesday, October 07, 2014 3:22 PM
> >> To: Ananyev, Konstantin
> >> Cc: dev at dpdk.org
> >> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
> >> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
> >>
> >>
> >> On Oct 7, 2014, at 4:09 AM, Ananyev, Konstantin >> intel.com> wrote:
> >>
> >>>
> >>>
> -Original Message-
> From: Wiles, Roger Keith [mailto:keith.wiles at windriver.com]
> Sent: Monday, October 06, 2014 9:08 PM
> To: Ananyev, Konstantin
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
>
> Attaching to the list does not work. If you want the code let me know it
> is only about 5K in size.
>
> On Oct 6, 2014, at 2:45 PM, Wiles, Roger Keith windriver.com> wrote:
>
> >
> > On Oct 6, 2014, at 11:13 AM, Wiles, Roger Keith > windriver.com> wrote:
> >
> >>
> >> On Oct 6, 2014, at 10:54 AM, Ananyev, Konstantin >> at intel.com> wrote:
> >>
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Bruce
> Richardson
> Sent: Monday, October 06, 2014 3:54 PM
> To: Wiles, Roger Keith (Wind River)
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 2/2] Adding the routines
> rte_pktmbuf_alloc_bulk() and rte_pktmbuf_free_bulk()
>
> On Mon, Oct 06, 2014 at 03:50:38PM +0100, Wiles, Roger Keith wrote:
> > Hi Bruce,
> >
> > Do I need to reject the for the new routines or just make sure the
> > vector driver does not get updated to use those
> routines?
> >
>
> The new routines are probably useful in the general case. I see no
> issue
> with having them in the code, so long as the vector driver is not
> modified
> to use them.
> >>>
> >>> I 'd say the same thing for non-vector RX/TX PMD code-paths too.
> >>>
> >>> BTW, are the new functions comments valid?
> >>>
> >>> + * @return
> >>> + * - 0 if the number of mbufs allocated was ok
> >>> + * - <0 is an ERROR.
> >>> + */
> >>> +static inline int __rte_mbuf_raw_alloc_bulk(
> >>>
> >>> Though, as I can see __rte_mbuf_raw_alloc_bulk() returns either:
> >>> - number of allocated mbuf (cnt)
> >>> - negative error code
> >>
> >> Let me fix up the comments.
> >>>
> >>> And:
> >>> + * @return
> >>> + * - The number of valid mbufs pointers in the m_list array.
> >>> + * - Zero if the request cnt could not be allocated.
> >>> + */
> >>> +static inline int __attribute__((always_inline))
> >>> +rte_pktmbuf_alloc_bulk(struct rte_mempool *mp, struct rte_mbuf
> >>> *m_list[], int16_t cnt)
> >>> +{
> >>> + return __rte_mbuf_raw_alloc_bulk(mp, m_list, cnt);
> >>> +}
> >>>
> >>> Shouldn't be "less than zero if the request cnt could not be
> >>> allocated."?
> >>>
> >>> BTW, is there any point to have __rte_mbuf_raw_alloc_bulk() at all?
> >>> After all, as you are calling rte_pktmbuf_reset() inside it, it
> >>> doesn't look __raw__ any more.
> >>> Might be just put its content into rte_pktmbuf_alloc_bulk() and get
> >>> rid of it.
> >>>
> >> I was just following the non-bulk routine style
> >> __rte_mbuf_raw_alloc(), but I can pull that into a single routine.
> >>
> >>> Also wonder, what is the advantage of having multiple counters inside
> >>> the same loop?
> >>> i.e:
> >>> + for(i = 0; i < cnt; i++) {
> >>> + m = *m_list++;
> >>>
> >>> Why not just:
> >>>
> >>> for(i = 0; i < cnt; i++) {
> >>> m = &m_list[i];
> >>>
> >>> Same for free:
> >>> + while(npkts--)
> >>> + rte_pktmbuf_free(*m_list++);
> >>>
> >>> While not just:
> >>> for (i = 0; i < npkts; i++)
> >>> rte_pktmbuf_free(&m_list[i]);
> >>
> >> Maybe I have it wrong or the compilers are doing the right thing now,
> >> but at one point the &m_list[i] would cause the
> compiler
> >> to
> generate a shift or multiple of 'i' and then add it to the base of
> m_list. If that is not the case anymore then I can update the code
> as
> you suggested. Using the *m_list++ just adds the size of a pointer to a
> register
[dpdk-dev] section mismatch warnings
On Mon, Oct 06, 2014 at 06:42:04PM +, Michael Hu (NSBU) wrote: > Hi Everyone, > > When we enable kernel config CONFIG_DEBUG_SECTION_MISMATCH=y and compile DPDK > 1.7 with 3.14.17 kernel + gcc 4.8.2, we got lots of warnings like these. > Do we have plan to fix them? If so, please advise on which version. Thanks. > Seems erroneous. These errors come from referencing symbols between incompatible sections (e.g. A static function reading a variable that is in an __initdata section). But theres nothing like that going on in any of these symbols referenced below (and the kernel version shouldn't matter, as this is all dpdk internal). It could be old objects in your build from a DPDK version where the symbols were in different sections. Do a make clean; git clean -f -d Then reconfigure and rebuild. I expect your issue will go away. Neil > > > == Build lib/librte_eal/linuxapp/kni > cut: /proc/version_signature: No such file or directory > LD > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/built-in.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o > Building modules, stage 2. > MODPOST 1 modules > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o(.data+0x20): > Section mismatch in reference from the variable igbuio_pci_driver to the > function .text:igbuio_pci_probe() > > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o(.data+0x28): > Section mismatch in reference from the variable igbuio_pci_driver to the > function .text:igbuio_pci_remove() > > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o(.data+0x130): > Section mismatch in reference from the variable dev_attr_max_vfs to the > function .text:show_max_vfs() > > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.o(.data+0x138): > Section mismatch in reference from the variable dev_attr_max_vfs to the > function .text:store_max_vfs() > > CC > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.mod.o > LD [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/igb_uio/igb_uio.ko > INSTALL-MODULE igb_uio.ko > > LD > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/built-in.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_main.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_api.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_common.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_ethtool.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_82599.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_82598.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_x540.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/ixgbe_phy.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/kcompat.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_82575.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_i210.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_api.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_mac.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_manage.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_mbx.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_nvm.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/e1000_phy.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_ethtool.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_hwmon.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_main.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_debugfs.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_param.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_procfs.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/igb_vmdq.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/kni_misc.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/kni_net.o > CC [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/kni_ethtool.o > LD [M] > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/rte_kni.o > WARNING: > /git/Pktgen-DPDK/dpdk/build/build/lib/librte_eal/linuxapp/kni/rte_kni.o(.data+0x20): > Section mismatch i
[dpdk-dev] [PATCH v2 00/18] Update IXGBE base code
On Tue, Oct 07, 2014 at 05:14:05PM +0200, Thomas Monjalon wrote: > Hi Ouyang, > > 2014-09-29 15:16, Ouyang Changchun: > > This patch series update IXGBE base code (a.k.a. share code) from > > package 2014.03.13 to package 2014.09.04 > > Applied > > You did a big work to split patches and I did another big work > to split all features and to make each commit compile-able > (with a minor exception). > As Neil asked, some comments are missing. But I push these commits > as is because base drivers are special and it's already a good improvement > since the last update submission. > I'm confident that the next one will be even better in comments and splitting. > Why would you do that? I don't see any reasoning behind why base drivers are "special" here. I had legitimate unanswered questions regarding this series. If you don't think my questions were relevant (specifically the question regarding code reachability), please indicate why its not worth waiting for an answer on. It seems to me like it wouldn't have been a hard question to settle (either explain the reachability path, or remove the code). Having the author ignore the question, and having you integrate the code anyway, is a recepie for promising questions like that never get addressed. Regards Neil
[dpdk-dev] [PATCH 0/4] Add DSO symbol versioning to support backwards compatibility
On Wed, Oct 01, 2014 at 02:59:40PM -0400, Neil Horman wrote: > On Fri, Sep 26, 2014 at 10:45:49AM -0400, Neil Horman wrote: > > On Fri, Sep 26, 2014 at 12:41:33PM +0200, Thomas Monjalon wrote: > > > Hi Neil, > > > > > > 2014-09-24 14:19, Neil Horman: > > > > Ping Thomas. I know you're busy, but I would like this to not fall off > > > > anyones > > > > radar. You alluded to concerns regarding what, for lack of a better > > > > term, > > > > ABI/API lockin. I had asked you to enuumerate/elaborate on specifics, > > > > but never > > > > heard back. Are there further specifics you wish to discuss, or are you > > > > satisfied with the above answers? > > > > > > Sorry for not being very reactive on this thread. > > > All this discussion is very interesting but it's really not the proper > > > time to apply it. As you said, it requires an extra effort. I'm not saying > > > it will never be integrated. I'm just saying that we cannot change > > > everything at the same time. > > > > > > Let me sum up the situation. This community project has been very active > > > for few months now. First, we learnt how to make some releases together > > > and we are improving the process to be able to deliver a new major release > > > every 4 months while having some good quality process. > > > But these releases are still not complete because documentation is not > > > integrated yet. Then developers should have a role in documentation > > > updates. > > > We also need to integrate and learn how to use more tools to be more > > > efficient and improve quality. > > > > > > So the question is "when should we care about API compatibility"? > > > And the answer is: ASAP, but not now. I feel next year is a better target. > > > Because the most important priority is to move together at a pace which > > > allow most of us to stay in the race. > > > > > > > > > I'm sorry Thomas, I don't accept this. I asked you for details as to your > > concerns regarding this patch series, and you've provided more vague > > comments. > > I need details to address > > > > You say it requires extra effort, you're right it does. Any feature that > > you > > integreate requires some additional effort. How is this patch any different > > from adding the acl library or any other new API? Everything requires > > maintenence, thats how software works. What specfically about this patch > > series > > makes the effort insurmountable to you? > > > > You say you're improving your process. Great, this patch aids in that > > process > > by ensuring backwards compatibility for a period of time. Given that the > > API > > and ABI can still evolve within this framework, as I've described, how is > > this > > patch series not a significant step forward toward your goal of quality > > process. > > > > You say documentation isn't integrated. So, what does getting documentation > > integrated have to do with this patch set, or any other? I don't see you > > holding any other patches based on documentation. Again, nothing in this > > series > > prevents evolution of the API or ABI. If you're hope is to wait until > > everything is perfect, then apply some control to the public facing API, > > and get > > it all documented, none of thosse things will ever happen, I promise you. > > > > You say you also need to learn to use more tools to be more efficient and > > improve quality. Great! Thats exactly what this is. If we mandate even a > > short > > term commitment to ABI stability (1 single relese worth of time), we will > > quickly identify what API's change quickly and where we need to be cautious > > with > > our API design. If you just assume that developers will get better of > > their own > > volition, it will never happen. > > > > You say this should go in next year, but not now. When exactly? What > > event do > > you forsee occuring in the next 12-18 months that will change everything > > such > > that we can start supporing an ABI for more than just a few weeks at the > > head of > > the tree? > > > > To this end, I just did a quick search through the git history for dpdk to > > look > > at the histories of all the header files that are exposed via the makefile > > SYMLINK command (given that that provides a list of header files that > > applications can include, and embodies all the function symbols and data > > types > > applications have access to. > > > > There are 179 total commits in that list > > Of those, a bit of spot checking suggests that about 10-15% of them actually > > change ABI, and many of those came from Bruce's rework of the mbuf > > structure. > > That about 17-20 instances over the last 2 years where an ABI update would > > have > > been needed. That seems pretty reasonable to me. Where exactly is your > > concern > > here? > > > > Neil > > > > Ping Thomas, I'd like to continue this debate to a conclusion. Could you > please > provide specific details and/or concerns that you ha
