> -Original Message-
> From: Shreyansh Jain [mailto:shreyansh.j...@nxp.com]
> Sent: Monday, October 09, 2017 10:01 PM
> To: Don Provan ; Jan Blunck ;
> Thomas Monjalon
> Cc: dev ; Hemant Agrawal
> Subject: Re: [dpdk-dev] [PATCH] eal: bus scan and probe never fail
>
formation to understand that application-level problem, so
they should leave it to the application to detect it.
-don provan
dpro...@bivio.net
> -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 a
> -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 c
t "rte_mbuf_raw_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
saying, it
is clearly useless. 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
ase it makes 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
no concept of using the library for anything
other than receiving packets from hardware.
-don provan
dprovan at bivio.net
the lines
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
one of those classic 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 pur
Looks perfect. Thanks!
-don
-Original Message-
From: Tiwei Bie [mailto:b...@mail.ustc.edu.cn]
Sent: Thursday, October 15, 2015 4:46 AM
To: Don Provan ; bruce.richardson at intel.com; dev at
dpdk.org
Subject: [PATCH] eal: don't reset getopt lib
Someone may need to call rte_eal
y comments? Thanks! :-)
Don't do it. Last time I looked, optind wasn't even mentioned in the
documentation. Even if I thought it was reasonable to change it,
I would still argue against using it as an undocumented return
value, particularly when the documented return value works fine.
-don provan
dprovan at bivio.net
the values 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
-
t 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
ization, but that's just an unfortunate
artifact of the library's history, not a rational design decision for moving
forward.
-don provan
ke fixed sizes, but I don't know enough 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: [
his has nothing to do with the point 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
private 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 s
> > > > > > > > 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
19 matches
Mail list logo
