> -Original Message-
> From: John Ousterhout [mailto:ouster at cs.stanford.edu]
> Sent: Tuesday, October 11, 2016 9:30 AM
> To: Thomas Monjalon
> Cc: dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v2] log: respect rte_openlog_stream calls
> before rte_eal_init
>
> On Tue, Oct 11, 2016
> -Original Message-
> From: Ananyev, Konstantin [mailto:konstantin.ananyev at intel.com]
> Sent: Thursday, July 21, 2016 3:51 AM
> Subject: Re: [dpdk-dev] [PATCH 04/12] mbuf: add function to calculate a
> checksum
>
>...
> > + Added a new function ``rte_pktmbuf_cksum()`` to process the
_release".
Logically I like this solution, as I'm very uncomfortable with the idea that a
free mbuf
might sometimes have refcnt set to one. On the other hand, if mbufs can often
be freed
without touching refcnt, that could be a big win that might persuade me to
accept being
uncomfortable.
-don provan
dprovan at bivio.net
The only reason to keep it would be that if such a feature
is added in the future, it could be added without changing the mbuf structure,
but I don't know whether that's important.
-don provan
dprovan at bivio.net
any difference to you. If it were
me, I'd probably decide it isn't hurting anything and not bother to remove it
in case some day someone wants to implement that feature in one driver or
another.
-don provan
dprovan at bivio.net
r anything
other than receiving packets from hardware.
-don provan
dprovan at bivio.net
of code.
It reduces the number of branches.
Is Duff's Device used in other "bulk" routines? If not, what justifies making
this a special case?
-don provan
dprovan at bivio.net
assic DPDK blindspots. The library can be used for
many
things entirely unrelated to hardware. My project has several DPDK applications
intended to be used by users that do not have privs to mess around with PCI
hardware, so, for them, turning off PCI wouldn't be just for debugging purposes.
-don prov
after. (And, from
what you're saying, optreset should be handled the same as optind.)
This avoids broken behavior if rte_eal_init() is called by code that's in the
middle of using getopt() to parse its own unrelated argc/argv parameters.
-don provan
dprovan at bivio.net
-Original Message
en it parses the corresponding command line flag.
The idea that there has to be one massive init routine which is
passed every possible configuration parameter is more of the same
monolithic thinking that DPDK needs to shake.
-don provan
dprovan at bivio.net
fortunate
artifact of the library's history, not a rational design decision for moving
forward.
-don provan
ough about your use
cases to say whether that makes sense here.
-don provan
dprovan at bivio.net
-Original Message-
From: Ravi Kerur [mailto:rke...@gmail.com]
Sent: Monday, May 11, 2015 1:47 PM
To: Ananyev, Konstantin
Cc: dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH v2] Implement memcmp us
being made here in your document, but
surely you want to insist on "static void usage(void)", right? In fact, you
might mention parameterless functions explicitly in the section on function
declarations.
Everything else looks pretty cool. I'm surprised and impressed.
-don provan
e data block and adjusting
the allocated dispatch table through that instead of through
the pointer to the immutable dispatch table you've established
in struct rte_eth_dev. That reinforces the fact that modifying
the dispatch table is a private matter within the driver while
showing structurally exactly wh
> > > > > > > > if (likely (rte_mbuf_refcnt_read(m) == 1) ||
> > > > > > > > likely (rte_mbuf_refcnt_update(m, -1)
> > > > > > > > == 0))
In all the debate about atomics, I don't think anyone got around to pointing
out that in the unlikely case that the refcnt is
15 matches
Mail list logo
