[dpdk-dev] [dpdk-announce] DPDK Features for Q1 2015
Hi Xie (2014/11/01 7:05), Xie, Huawei wrote: > Hi Tetsuya: > I am implementing vhost-user, and the functionality works now. > During this work, I have refactored vhost code a bit for better > modularization, basically > virtio part, control message part(vhost-user, vhost cuse) and data part. :). > Let us see your patch, if its modularization is further, I will generate the > vhost-user patch based on yours rather than mine, :). Sure. My patches are based on old your librte_vhost patches. So I will rebase my patches and send it in few days. Thanks, Tetsuya
[dpdk-dev] Fwd: FOSDEM conference - call for participation
Stephen, According to Dave (cc'd): it cannot be applied for FOSDEM; the organizers would not be happy if we proposed that. Best regards, Vincent On 01/11/2014 22:43, Stephen Hemminger wrote: > Rather than individual talks what about getting them to schedule a 1/2 day > unconference? > > On Fri, Oct 31, 2014 at 3:53 PM, Thomas Monjalon 6wind.com> > wrote: > >> Hi, >> >> Talks related to DPDK can be proposed for FOSDEM 2015: >> https://fosdem.org/2015/ >> This conference will take place in Belgium on 31 January & 1 February. >> >> -- >> Thomas >> >> Forwarded Message >> Subject: Network devroom call for participation >> Date: Fri, 31 Oct 2014 17:33:33 -0400 >> From: Dave Neary >> To: Pavel Simerda , >> network-devroom at lists.fosdem.org, fosdem at lists.fosdem.org >> >> Hi everyone, >> >> We are pleased to announce the Call for Participation in the FOSDEM >> 2015 Networking DevRoom! >> >> Important dates: >> * Nov 25: Deadline for submissions >> * Dec 1: Speakers notified of acceptance >> * Dec 5: Schedule published >> >> This is the first time that networking has been included as a >> stand-alone DevRoom, and this year the topics will cover two distinct >> fields: >> * Software Defined Networking (SDN), covering virtual switching, open >> source SDN controllers, virtual routing >> * Network management, covering host-level networking - NetworkManager, >> ConnMan, systemd, wicked, kernel network services, network security, etc >> >> >> We are now inviting proposals for talks about Free/Libre/Open-source >> Software on the topics of SDN and network management. This is an >> exciting and growing field, and this is a unique opportunity to show >> novel ideas and developments to a very knowledgeable technical audience. >> >> Topics accepted include, but are not limited to: >> >> SDN: >> * SDN controllers - OpenDaylight, OpenContrail, OpenStack Neutron >> * Dataplane processing: DPDK, OpenDataplane, netdev, netfilter >> * Virtual switches: Open vSwitch, Snabb Switch, VDE >> * Open network protocols: OpenFlow, NETCONF, OpenLISP >> >> Network management: >> * Network management: NetworkManager, ConnMan, systemd-networkd, >> interoperability among these projects >> * Common code infrastructure: libnl, libmnl, libsystemd, ell, pyroute2 >> * Network services: DHCP, DNS, DNSSEC, PPP >> * Connection management: Wifi, tethering, connection sharing, metric and >> source based routing, >> >> Talks should be aimed at a technical audience, but should not assume >> that attendees are already familiar with your project or how it solves a >> general problem. Talk proposals can be very specific solutions to a >> problem, or can be higher level project overviews for lesser known >> projects. >> >> Please include the following information when submitting a proposal: >> >> Your name >> The title of your talk (please be descriptive, as titles will be >> listed with around 250 from other projects) >> Short abstract of one or two paragraphs >> Short bio (with photo) >> >> The deadline for submissions is November 25th 2014. FOSDEM will be held >> on the weekend of January 31st-February 1st 2015 and the Networking >> DevRoom will take place on Saturday, January 31st 2015. Please use the >> following website to submit your proposals: >> https://penta.fosdem.org/submission/FOSDEM15 (you do not need to create >> a new Pentabarf account if you already have one from past years). >> >> You can also join the devroom?s mailing list, which is the official >> communication channel for the DevRoom: network-devroom at lists.fosdem.org >> (subscription page: https://lists.fosdem.org/listinfo/network-devroom) >> >> ? The Networking DevRoom 2015 Organization Team >> >> -- >> Dave Neary - NFV/SDN Community Strategy >> Open Source and Standards, Red Hat - http://community.redhat.com >> Ph: +1-978-399-2182 / Cell: +1-978-799-3338 >>
[dpdk-dev] [PATCH v6] distributor_app: new sample app
Hi Reshma,
> -Original Message-
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Reshma Pattan
[...]
> diff --git a/examples/distributor_app/main.c
> b/examples/distributor_app/main.c
> new file mode 100644
> index 000..c9994a6
> --- /dev/null
> +++ b/examples/distributor_app/main.c
> @@ -0,0 +1,642 @@
[...]
> +static const struct rte_eth_rxconf rx_conf_default = {
> + .rx_thresh = {
> + .pthresh = RX_PTHRESH,
> + .hthresh = RX_HTHRESH,
> + .wthresh = RX_WTHRESH,
> + },
> + .rx_free_thresh = RX_FREE_THRESH,
> + .rx_drop_en = 0,
> +};
> +
> +static const struct rte_eth_txconf tx_conf_default = {
> + .tx_thresh = {
> + .pthresh = TX_PTHRESH,
> + .hthresh = TX_HTHRESH,
> + .wthresh = TX_WTHRESH,
> + },
> + .tx_free_thresh = TX_FREE_THRESH,
> + .tx_rs_thresh = TX_RSBIT_THRESH,
> + .txq_flags = TX_Q_FLAGS
> +
> +};
You can remove these two structures (and all the macros involved),
if you pass NULL to rxconf/txconf parameters when calling RX/TX queue setup.
[...]
> +static inline int
> +port_init(uint8_t port, struct rte_mempool *mbuf_pool)
> +{
> + struct rte_eth_conf port_conf = port_conf_default;
> + const uint16_t rxRings = 1, txRings = rte_lcore_count() - 1;
> + int retval;
> + uint16_t q;
> +
> + if (port >= rte_eth_dev_count())
> + return -1;
> +
> + retval = rte_eth_dev_configure(port, rxRings, txRings, &port_conf);
> + if (retval != 0)
> + return retval;
> +
> + for (q = 0; q < rxRings; q++) {
> + retval = rte_eth_rx_queue_setup(port, q, RX_RING_SIZE,
> +
> rte_eth_dev_socket_id(port),
> + &rx_conf_default,
> mbuf_pool);
Recently, a new functionality has been added for RX/TX queue setup.
You can now use NULL as rxconf/txconf parameter, so it will use
the optimal configuration, so it will save you some lines of code and simplify
it.
> + if (retval < 0)
> + return retval;
> + }
> +
> + for (q = 0; q < txRings; q++) {
> + retval = rte_eth_tx_queue_setup(port, q, TX_RING_SIZE,
> +
> rte_eth_dev_socket_id(port),
> + &tx_conf_default);
> + if (retval < 0)
> + return retval;
> + }
> +
> + retval = rte_eth_dev_start(port);
Remove second space before "=".
> + if (retval < 0)
> + return retval;
> +
[...]
> + rte_distributor_process(d, NULL, 0);
> + /* flush distributor to bring to known state */
> + rte_distributor_flush(d);
> + /* set worker & tx threads quit flag */
> + quit_signal = 1;
> + /* worker threads may hang in get packet as
> +distributor process is not runnig, just make sure workers
> +gets packets till quit_signal is actually been
> +received and they gracefully shutdown*/
Typos in "running" and "workers gets". Plus, use standard multi-line comments.
> + quit_workers(d, mem_pool);
> + /* rx thread should quit at last*/
> + return 0;
> +}
> +
[...]
> +static int
> +lcore_worker(struct lcore_params *p)
> +{
> + struct rte_distributor *d = p->d;
> + const unsigned id = p->worker_id;
> + /* for single port, xor_val will be zero so we won't modify the output
> + * port, otherwise we send traffic from 0 to 1, 2 to 3, and vice versa
> + */
Move "/*" to the first line, to be consistent with other multi-line comments.
> + const unsigned xor_val = (rte_eth_dev_count() > 1);
> + struct rte_mbuf *buf = NULL;
> +
> + printf("\nCore %u acting as worker core.\n", rte_lcore_id());
> + while (!quit_signal) {
> + buf = rte_distributor_get_pkt(d, id, buf);
> + buf->port ^= xor_val;
> + }
> + return 0;
[...]
> + default:
> + print_usage(prgname);
> + return -1;
> + }
> + }
> +
> +if (optind <= 1) {
> + print_usage(prgname);
> + return -1;
> +}
Missing indentation.
> +
> + argv[optind-1] = prgname;
> +
> + optind = 0; /* reset getopt lib */
> + return 0;
> +}
Thanks,
Pablo
[dpdk-dev] Q on contribution to DPDK
Hi, There are many ways of contributing to DPDK. Apart features and fixes, I'd suggest these 4 activities: - Bug reporting is critical to satisfy all use cases - Patch reviews are very important and help to accelerate their integration - Clean-up (e.g. remove doxygen warnings, merge linux and bsd eal, etc) - Documentation Welcome :) PS: inline replies are preferred in general -- Thomas 2014-10-31 15:53, r k: > Hi Jim, > > Thanks for your response. I did check DPDK roadmap and it wasn't clear > to me what's available to be implemented. In addition, roadmap lists > features but doesn't give description as to what needs to be done. It > might be no brainer for original developers but it will definitely > help outsiders if some information is provided. Also I was thinking if > I can start-off with bug fixing initially to get acquainted with the > code and then start off with more things. Please let me know your > inputs. > > Thanks, > Ravi > > > On Fri, Oct 31, 2014 at 3:16 PM, St Leger, Jim > wrote: > > Ravi: > > > > DPDK is an open source community project. Anyone and everyone are welcome > > and encouraged to contribute patches. There should not be any concern about > > individual contributors versus company affiliation. What matters is useful > > code. > > Please review the Development page on the site for guidance: > > http://dpdk.org/dev > > > > If you have particular areas of interest or expertise just share that with > > the list. > > > > I look forward to your contributions. > > > > Jim > > > > -Original Message- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of r k > > Sent: Friday, October 31, 2014 2:39 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] Q on contribution to DPDK > > > > Hello DPDK development team, > > > > I am interested in contributing to DPDK and wanted to know a way of > > contributing to it. Some questions > > > > 1. Will DPDK accept patches from community? I will be individual > > contributor with no affiliation to any company. > > > > 2. If answer is "Yes" to previous question, should I look at DPDK > > development roadmap and pick one from that? > > > > Inputs appreciated. > > > > Thanks, > > Ravi
[dpdk-dev] [PATCH] Allow verbose output for INSTALL-SHARED
Signed-off-by: Keith Wiles --- mk/rte.shared.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mk/rte.shared.mk b/mk/rte.shared.mk index 42feee7..e64d471 100644 --- a/mk/rte.shared.mk +++ b/mk/rte.shared.mk @@ -114,7 +114,7 @@ $(SHARED): $(OBJS-y) $(LDLIBS_FILES) $(DEP_$(SHARED)) FORCE # $(RTE_OUTPUT)/lib/$(SHARED): $(SHARED) @echo " INSTALL-SHARED $(SHARED)" - @[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib + $(Q)[ -d $(RTE_OUTPUT)/lib ] || mkdir -p $(RTE_OUTPUT)/lib $(Q)cp -f $(SHARED) $(RTE_OUTPUT)/lib # -- 2.1.0
[dpdk-dev] [PATCH] Add external parser support for unknown commands.
Allow for a external parser to handle the command line if the
command is not found and the developer has called the routine
int cmdline_set_external_parser(struct cmdline * cl,
cmdline_external_parser_t parser);
function to set the function pointer.
The function for the external parser function should return
CMDLINE_PARSE_NOMATCH
if not able to match the command requested or zero is handled.
Prototype of external routine:
int (*cmdline_external_parser_t)(struct cmdline * cl, const char * buy);
Signed-off-by: Keith Wiles
---
lib/librte_cmdline/cmdline.h | 4
lib/librte_cmdline/cmdline_parse.c | 12 +++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/lib/librte_cmdline/cmdline.h b/lib/librte_cmdline/cmdline.h
index 4c28d37..f15d996 100644
--- a/lib/librte_cmdline/cmdline.h
+++ b/lib/librte_cmdline/cmdline.h
@@ -65,6 +65,8 @@
extern "C" {
#endif
+typedef int (*cmdline_external_parser_t)(struct cmdline * cl, const char *
buf);
+
struct cmdline {
int s_in;
int s_out;
@@ -74,6 +76,7 @@ struct cmdline {
#ifdef RTE_EXEC_ENV_LINUXAPP
struct termios oldterm;
#endif
+ cmdline_external_parser_t external_parser;
};
struct cmdline *cmdline_new(cmdline_parse_ctx_t *ctx, const char *prompt, int
s_in, int s_out);
@@ -85,6 +88,7 @@ int cmdline_in(struct cmdline *cl, const char *buf, int size);
int cmdline_write_char(struct rdline *rdl, char c);
void cmdline_interact(struct cmdline *cl);
void cmdline_quit(struct cmdline *cl);
+void cmdline_set_external_parser(struct cmdline * cl,
cmdline_external_parser_t parser);
#ifdef __cplusplus
}
diff --git a/lib/librte_cmdline/cmdline_parse.c
b/lib/librte_cmdline/cmdline_parse.c
index 940480d..a65ae70 100644
--- a/lib/librte_cmdline/cmdline_parse.c
+++ b/lib/librte_cmdline/cmdline_parse.c
@@ -212,6 +212,14 @@ match_inst(cmdline_parse_inst_t *inst, const char *buf,
return i;
}
+/* Set or disable external parser */
+void
+cmdline_set_external_parser(struct cmdline *cl, cmdline_external_parser_t
parser)
+{
+ /* If parser is NULL it allows for disabling external parser */
+ if ( cl )
+ cl->external_parser = parser;
+}
int
cmdline_parse(struct cmdline *cl, const char * buf)
@@ -320,7 +328,9 @@ cmdline_parse(struct cmdline *cl, const char * buf)
/* no match */
else {
debug_printf("No match err=%d\n", err);
- return err;
+ if ( cl->external_parser == NULL )
+ return err;
+ return cl->external_parser(cl, buf);
}
return linelen;
--
2.1.0
