s function removes the struct
kni_dev from the list of interfaces to poll (and kills the per-dev
kthread, if configured for multi-thread), then frees the memory in
the FIFOs.
Signed-off-by: Dan Gora
I'm not sure that this is exactly the problem that you're seeing, but
it
Hi All,
Sorry to butt in on this, but I fixed this same issue about 3 years
ago in my application, but I was never able to get the changes
integrated and eventually just gave up trying.
The rule with KNI is:
1) The app should have a separate control thread per rte_kni which
just spins calling rte
On Mon, Jun 29, 2020 at 6:06 PM Mattias Rönnblom
wrote:
>
> It's unlikely to fail, and if it does something is probably seriously
> wrong with your system. You also seem to think it might fail, since you
> take great care of setting errno and having non-zero return code in
> __rte_getentropy().
W
On Mon, Jun 29, 2020 at 3:01 PM Dan Gora wrote:
>
> On Mon, Jun 29, 2020 at 6:32 AM Mattias Rönnblom
> wrote:
> >
> > On 2020-04-23 01:42, Dan Gora wrote:
> > > Hi All,
> > >
> > > The following patches updates the rte_random subsystem to dynam
On Mon, Jun 29, 2020 at 6:32 AM Mattias Rönnblom
wrote:
>
> On 2020-04-23 01:42, Dan Gora wrote:
> > Hi All,
> >
> > The following patches updates the rte_random subsystem to dynamically find
> > the best source of the initial seed to the PRNG at run time.
> >
On Mon, Jun 29, 2020 at 6:30 AM Mattias Rönnblom
wrote:
>
> On 2020-04-23 01:42, Dan Gora wrote:
> > The getentropy() function was introduced into glibc v2.25 and so is
> > not available on all supported platforms. Previously, if DPDK was
> > compiled (using meso
On Tue, Jun 2, 2020 at 2:10 AM Dan Gora wrote:
>
> Can these patches be considered again for 20.08?
>
> I thought that I addressed all of the issues or at least provided
> reasonable responses to all of the concerns.
So I guess I'll take that as a "no"...
I hav
Can these patches be considered again for 20.08?
I thought that I addressed all of the issues or at least provided
reasonable responses to all of the concerns.
thanks
dan
On Mon, May 4, 2020 at 11:19 AM Dan Gora wrote:
>
> On Mon, May 4, 2020 at 11:13 AM Dan Gora wrote:
> >
>
On Mon, May 4, 2020 at 11:13 AM Dan Gora wrote:
>
> On Mon, May 4, 2020 at 5:04 AM Mattias Rönnblom
> wrote:
>
> > >> so what you are effectively asking is to
> > >> double the size of the support matrix, and for the project to ensure
> > >>
On Mon, May 4, 2020 at 5:04 AM Mattias Rönnblom
wrote:
> >> so what you are effectively asking is to
> >> double the size of the support matrix, and for the project to ensure
> >> that every single dependency can always be built against a new version
> >> and used against an older one.
> > No, th
On Fri, May 1, 2020 at 1:29 PM Luca Boccassi wrote:
> >
> > Well, no, because rdseed is used first if available and /dev/urandom
> > is used next..
> >
> > And this is not a corner case at all.. There are lots of linux
> > distributions which DPDK claims to support which do not support
> > getentr
On Thu, Apr 30, 2020 at 5:29 PM Luca Boccassi wrote:
> > > Adding a new dependecy happens only when building with the new version
> > > of the library. If it's not available, then there's no new dependency.
> >
> > But you also do not get to use the new getentropy() if you happen to
> > compile o
On Mon, Apr 27, 2020 at 1:19 PM Luca Boccassi wrote:
>
> On Thu, 2020-04-23 at 14:38 -0300, Dan Gora wrote:
> > On Thu, Apr 23, 2020 at 12:59 PM Luca Boccassi wrote:
> > > > > /dev/urandom is basically only a different interface to the same
> > > > > und
On Wed, Apr 22, 2020 at 11:39 PM Stephen Hemminger
wrote:
>
> On Wed, 22 Apr 2020 20:42:54 -0300
> Dan Gora wrote:
>
> > + fd = open("/dev/urandom", O_RDONLY);
> > + if (fd < 0) {
> > + errno = ENODEV;
> > + r
On Thu, Apr 23, 2020 at 12:59 PM Luca Boccassi wrote:
> > >
> > > /dev/urandom is basically only a different interface to the same
> > > underlying mechanism.
>
> This is not the whole story though - while the end result when all
> works is the same, there are important differences in getting ther
On Thu, Apr 23, 2020 at 9:36 AM Mattias Rönnblom
wrote:
> >>
> >> /dev/urandom is basically only a different interface to the same
> >> underlying mechanism.
> >>
> >> Such an alternative would look something like:
> >>
> >> static int
> >> getentropy(void *buffer, size_t length)
> >> {
> >>
RTE_COMPILE_TIME_CPUFLAGS
which are checked in rte_eal_init() at run time because it is no longer
required to match the compilation system.
Signed-off-by: Dan Gora
---
config/x86/meson.build | 11 ---
lib/librte_eal/common/rte_random.c | 19 +++
mk/rte.cpuflags.mk
remove
this dependency on the glibc version.
Since __rte_genentropy() should never fail, the rdseed method is
tried first.
Signed-off-by: Dan Gora
---
lib/librte_eal/common/rte_random.c | 62 ++
lib/librte_eal/meson.build | 3 --
2 files changed, 54
ls in __rte_getentropy().
v3:
* Fix error checking of dlsym() in __rte_getentropy().
* Style changes recommended by Mattias.
v4:
* Replace dlopen/dlsym method with reading from /dev/urandom.
* Try rdseed method before getentropy() method since the
latter should never fail.
Dan Gora (2):
eal:
On Wed, Apr 22, 2020 at 5:14 PM Mattias Rönnblom
wrote:
>
> On 2020-04-22 19:44, Dan Gora wrote:
> > On Wed, Apr 22, 2020 at 5:28 AM Mattias Rönnblom
> > wrote:
> >> On 2020-04-21 21:54, Dan Gora wrote:
> >>> The getentropy() function was introduced into gl
RTE_COMPILE_TIME_CPUFLAGS
which are checked in rte_eal_init() at run time because it is no longer
required to match the compilation system.
Signed-off-by: Dan Gora
---
config/x86/meson.build | 11 ---
lib/librte_eal/common/rte_random.c | 19 +++
mk/rte.cpuflags.mk
dlopen()/dlsym(),
returning failure if the getentropy() function cannot be resolved or
if it fails.
This also allows getentropy() to be used as the random seed source
when the traditional Makefile build for DPDK is used.
Signed-off-by: Dan Gora
---
lib/librte_eal/common/rte_random.c | 36
system, regardless of whether or not it was
available on the compilation system.
Thanks
Dan
-
v2:
* Fix patch apply issue.
* dlclose() handle if dlsym() fails in __rte_getentropy().
v3:
* Fix error checking of dlsym() in __rte_getentropy().
* Style changes recommended by Mattias.
Dan Gora (2
On Wed, Apr 22, 2020 at 5:28 AM Mattias Rönnblom
wrote:
>
> On 2020-04-21 21:54, Dan Gora wrote:
> > The getentropy() function was introduced into glibc v2.25 and so is
> > not available on all supported platforms. Previously, if DPDK was
> > compiled (using meso
On Tue, Apr 21, 2020 at 6:03 PM Stephen Hemminger
wrote:
>
> On Tue, 21 Apr 2020 16:54:45 -0300
> Dan Gora wrote:
>
> > The getentropy() function was introduced into glibc v2.25 and so is
> > not available on all supported platforms. Previously, if DPDK was
> &g
dlopen()/dlsym(),
returning failure if the getentropy() function cannot be resolved or
if it fails.
This also allows getentropy() to be used as the random seed source
when the traditional Makefile build for DPDK is used.
Signed-off-by: Dan Gora
---
lib/librte_eal/common/rte_random.c | 35
system, regardless of whether or not it was
available on the compilation system.
Thanks
Dan
-
v2:
* Fix patch apply issue.
* dlclose() handle if dlsym() fails in __rte_getentropy().
Dan Gora (2):
eal: check for rdseed at run time for random seed
eal: resolve getentropy at run time for random
RTE_COMPILE_TIME_CPUFLAGS
which are checked in rte_eal_init() at run time because it is no longer
required to match the compilation system.
Signed-off-by: Dan Gora
---
config/x86/meson.build | 11 ---
lib/librte_eal/common/rte_random.c | 19 +++
mk/rte.cpuflags.mk
RTE_COMPILE_TIME_CPUFLAGS
which are checked in rte_eal_init() at run time because it is no longer
required to match the compilation system.
Signed-off-by: Dan Gora
---
config/x86/meson.build | 11 ---
lib/librte_eal/common/rte_random.c | 19 +++
mk/rte.cpuflags.mk
dlopen()/dlsym(),
returning failure if the getentropy() function cannot be resolved or
if it fails.
This also allows getentropy() to be used as the random seed source
when the traditional Makefile build for DPDK is used.
Signed-off-by: Dan Gora
---
lib/librte_eal/common/rte_random.c | 33
system, regardless of whether or not it was
available on the compilation system.
Thanks
Dan
Dan Gora (2):
eal: check for rdseed at run time for random seed
eal: resolve getentropy at run time for random seed
config/x86/meson.build | 11 +--
lib/librte_eal/common/rte_random.c | 50
On Thu, Apr 16, 2020 at 8:30 AM Mattias Rönnblom
wrote:
> > diff --git a/lib/librte_eal/meson.build b/lib/librte_eal/meson.build
> > index 0267c3b9d..748359b8c 100644
> > --- a/lib/librte_eal/meson.build
> > +++ b/lib/librte_eal/meson.build
> > @@ -15,9 +15,6 @@ deps += 'kvargs'
> > if dpdk_conf
entropy source.
This also allows non-meson builds to use getentropy().
Signed-off-by: Dan Gora
---
v2:
* Rebase to latest master.
* Fix spelling of "meson".
config/x86/meson.build | 7 +++
lib/librte_eal/common/rte_random.c | 29 -
lib/
entropy source.
This also allows non-Mason builds to use getentropy().
Signed-off-by: Dan Gora
---
config/x86/meson.build | 7 +++
lib/librte_eal/common/rte_random.c | 29 -
lib/librte_eal/meson.build | 3 ---
mk/rte.cpuflags.mk
Here's another link to the thread where this was discussed last year..
Igor was actually on this thread as well...
https://mails.dpdk.org/archives/dev/2018-August/110383.html
On Mon, Oct 14, 2019 at 4:01 PM Dan Gora wrote:
>
> My original patch to add this feature was basically the
My original patch to add this feature was basically the same thing as
this: setting the link status via a KNI ioctl. That method was
rejected after _much_ discussion and we eventually settled on the
currently implementation.
My original patch was here: Message-Id: <20180628225548.21885-1...@adax.c
Add the new module parameter for the KNI kernel module, the new command
line flag for the KNI sample application, and the new API function
'rte_kni_update_link()' to the release note.
Signed-off-by: Dan Gora
---
doc/guides/rel_notes/release_18_11.rst | 19 +++
1 file c
On Mon, Nov 5, 2018 at 5:06 PM Ferruh Yigit wrote:
> > +* kni: Added the new API function ``rte_kni_update_link()`` to allow the
> > user
> > + to set the carrier state of the KNI kernel network interface.
> > +
>
> It is good to document new API, which can be on "new features" section above,
>
On Mon, Nov 5, 2018 at 4:23 PM Dan Gora wrote:
>
> On Mon, Nov 5, 2018 at 4:21 PM Ferruh Yigit wrote:
> > There is no test plan documentation within dpdk repo. There is DTS (dpdk
> > test
> > suit) in a separate repo [1], which needs to be updated, and indeed this
&
Add the new module parameter for the KNI kernel module, the new command
line flag for the KNI sample application, and the new API function
'rte_kni_update_link()' to the release note.
Signed-off-by: Dan Gora
---
doc/guides/rel_notes/release_18_11.rst | 13 +
1 file c
On Mon, Nov 5, 2018 at 4:21 PM Ferruh Yigit wrote:
> There is no test plan documentation within dpdk repo. There is DTS (dpdk test
> suit) in a separate repo [1], which needs to be updated, and indeed this patch
> is to point them the change because existing test is failing after changes...
>
> [1
Hi Ferruh,
On Mon, Nov 5, 2018 at 3:28 PM Ferruh Yigit wrote:
>
> Commit 89397a01ce4a ("kni: set default carrier state of interface")
> changes the KNI interface default carrier status. Which prevents traffic
> flow by default and may break some existing usage / testing.
>
> Document this behavio
Don't use .svg extension on ..figure references. PDF versions of
the documents use .png images generated from the .svg images.
Fixes: 0ba610ca1d17 ("net/mvpp2: document MTR and TM usage")
Cc: nsams...@marvell.com
Signed-off-by: Dan Gora
---
doc/guides/nics/mvpp2.rst | 2 +-
1
It looks like it's choking on a figure in the mvpp2.rst file:
guides/nics/mvpp2.rst:.. figure:: img/mvpp2_tm.svg
Reverting commit 0ba610ca1d178cbeedba6e033ee399dfe773801e fixes it.
This fixes it too:
diff --git a/doc/guides/nics/mvpp2.rst b/doc/guides/nics/mvpp2.rst
index 59fa0e10d..10303a1c1 1
rx/tx_packets
in worker threads by a non-zero amount. This limits the race to the
periods in which traffic is actually being received or transmitted.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/examples/kni/main.c b
n be set to 'on'. This enables the KNI interface to be
used without having to explicity set the carrier state to 'on'
using rte_kni_update_link().
Signed-off-by: Dan Gora
---
.../prog_guide/kernel_nic_interface.rst | 239 ++
kernel/linux/kni/kni_dev.h
Update KNI example to add the command line flag '-m' to enable
a function to continuously monitor the Ethernet link status of
the physical link and update the link status of the corresponding
interfaces with rte_kni_update_link().
Signed-off-by: Dan Gora
---
.../sam
Add logging messages showing the commands necessary for the user to
have the application display and zero the statistics.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/examples/kni/main.c b/examples/kni
Add a new API function to KNI, rte_kni_update_link() to allow DPDK
applications to update the link status for KNI network interfaces in
the linux kernel.
Signed-off-by: Dan Gora
---
lib/librte_kni/rte_kni.c | 41
lib/librte_kni/rte_kni.h | 20
lib
o examples/kni: Add log message showing how
> to show/zero stats. Improve zeroing statistics.
>
> Note that checkpatches.sh compains about patch 1/5, but this appears
> to be a bug with check-symbol-change or something. If I move the
> fragment of the patch modifying rte_kni_versi
On Wed, Oct 24, 2018 at 6:18 PM Stephen Hemminger
wrote:
> > >
> > > This seems like an overly wordy message which should really be in the
> > > documentation
> > > not a billboard in the code.
> > >
> > > In my opinion, having verbose messages is unhelpful since it just clutters
> > > the experi
On Wed, Oct 24, 2018 at 5:46 PM Stephen Hemminger
wrote:
> > + pid = getpid();
> > + RTE_LOG(INFO, APP, "\n");
> > + RTE_LOG(INFO, APP, "KNI Running\n");
> > + RTE_LOG(INFO, APP, "kill -SIGUSR1 %d\n", pid);
> > + RTE_LOG(INFO, APP, "Show KNI Statisti
Add logging messages showing the commands necessary for the user to
have the application display and zero the statistics.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/examples/kni/main.c b/examples/kni
rx/tx_packets
in worker threads by a non-zero amount. This limits the race to the
periods in which traffic is actually being received or transmitted.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/examples/kni/main.c b
k status and
> update the corresponding kernel interface with
> rte_kni_update_link().
>
> * Minor improvements to examples/kni: Add log message showing how
> to show/zero stats. Improve zeroing statistics.
>
> Note that checkpatches.sh compains about patch 1/5, but this
n be set to 'on'. This enables the KNI interface to be
used without having to explicity set the carrier state to 'on'
using rte_kni_update_link().
Signed-off-by: Dan Gora
---
.../prog_guide/kernel_nic_interface.rst | 239 ++
kernel/linux/kni/kni_dev.h
Update KNI example to add the command line flag '-m' to enable
a function to continuously monitor the Ethernet link status of
the physical link and update the link status of the corresponding
interfaces with rte_kni_update_link().
Signed-off-by: Dan Gora
---
.../sam
Add a new API function to KNI, rte_kni_update_link() to allow DPDK
applications to update the link status for KNI network interfaces in
the linux kernel.
Signed-off-by: Dan Gora
---
lib/librte_kni/rte_kni.c | 41
lib/librte_kni/rte_kni.h | 20
lib
On Mon, Oct 22, 2018 at 9:51 AM Ferruh Yigit wrote:
> > +Running the kni Example Application
> > +---
> >
> > -Loading the KNI kernel module without any parameter is the typical way a
> > DPDK application
> > -gets packets into and out of the kernel net stack.
> >
Add logging messages showing the commands necessary for the user to
have the application display and zero the statistics.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/examples/kni/main.c b/examples/kni
rx/tx_packets
in worker threads by a non-zero amount. This limits the race to the
periods in which traffic is actually being received or transmitted.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/examples/kni/main.c b
Update KNI example to add the command line flag '-m' to enable
a function to continuously monitor the Ethernet link status of
the physical link and update the link status of the corresponding
interfaces with rte_kni_update_link().
Signed-off-by: Dan Gora
---
.../sam
Add a new API function to KNI, rte_kni_update_link() to allow DPDK
applications to update the link status for KNI network interfaces in
the linux kernel.
Signed-off-by: Dan Gora
---
lib/librte_kni/rte_kni.c | 41
lib/librte_kni/rte_kni.h | 20
lib
n be set to 'on'. This enables the KNI interface to be
used without having to explicity set the carrier state to 'on'
using rte_kni_update_link().
Signed-off-by: Dan Gora
---
.../prog_guide/kernel_nic_interface.rst | 203 ++
kernel/linux/kni/kni_dev.h
show/zero stats. Improve zeroing statistics.
>
> Note that checkpatches.sh compains about patch 1/5, but this appears
> to be a bug with check-symbol-change or something. If I move the
> fragment of the patch modifying rte_kni_version.map to the bottom of
> the patch file, it doesn'
On Thu, Oct 18, 2018 at 10:44 AM Ferruh Yigit wrote:
>
> KNI sample application calls this API each 100ms, so this keeps writing
> "carrier" file.
>
> What do you think writing to "carrier" file only if status changed?
>
> And it is possible to register to RTE_ETH_EVENT_INTR_LSC event in sample
>
Ok, never mind.. I see that it was fixed right after I pulled yesterday...
commit 41c24ea294fe6c69ee8c1b814c2475af0e74d821 (net/dpaa2: fix MAC
address initialization)
On Wed, Oct 17, 2018 at 8:44 PM Dan Gora wrote:
>
> Hi All,
>
> I sent a patch yesterday to fix a compilation fa
Hi All,
I sent a patch yesterday to fix a compilation failure in the
test_external_mem test and I pulled origin yesterday and now there is
another compilation failure which was introduced in commit
c3e0a706fd7595733cf51 (net/dpaa2: read hardware provided MAC for DPNI
devices):
/home/dg/Network_Fa
Update KNI example to add the command line flag '-m' to enable
a function to continuously monitor the Ethernet link status of
the physical link and update the link status of the corresponding
interfaces with rte_kni_update_link().
Signed-off-by: Dan Gora
---
examples/kni/Mak
rx/tx_packets
in worker threads by a non-zero amount. This limits the race to the
periods in which traffic is actually being received or transmitted.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/examples/kni/main.c b
Add logging messages showing the commands necessary for the user to
have the application display and zero the statistics.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/examples/kni/main.c b/examples/kni
n be set to 'on'. This enables the KNI interface to be
used without having to explicity set the carrier state to 'on'
using rte_kni_update_link().
Signed-off-by: Dan Gora
---
kernel/linux/kni/kni_dev.h | 3 +++
kernel/linux/kni/kni_misc.c | 40 +++
Add a new API function to KNI, rte_kni_update_link() to allow DPDK
applications to update the link status for KNI network interfaces in
the linux kernel.
Signed-off-by: Dan Gora
---
lib/librte_kni/rte_kni.c | 41 ++
lib/librte_kni/rte_kni.h | 20
Test changing the link status of the KNI interface with
rte_kni_update_link().
Signed-off-by: Dan Gora
---
test/test/test_kni.c | 77
1 file changed, 77 insertions(+)
diff --git a/test/test/test_kni.c b/test/test/test_kni.c
index cf64c0b27
ovements to examples/kni: Add log message showing how
> to show/zero stats. Improve zeroing statistics.
>
> Note that checkpatches.sh compains about patch 1/5, but this appears
> to be a bug with check-symbol-change or something. If I move the
> fragment of the patch modifying r
; i++) {
^
test_external_mem.c:375:2: note: use option -std=c99 or -std=gnu99 to
compile your code
Fixes: b270daa43b3d ("test: support external memory")
Cc: anatoly.bura...@intel.com
Signed-off-by: Dan Gora
---
test/test/test_external_mem.c | 3 ++-
1 file changed, 2 ins
I'll have a look at this.. Maybe it will work, I'll have to try it and
test it to see if there are any gotchas that are not obvious.
d
On Wed, Oct 10, 2018 at 7:51 PM Ferruh Yigit wrote:
> >> Very simply, what about prevent kni_net_release() send callback to
> >> userspace?
> >
> > No, because
On Wed, Oct 10, 2018 at 8:00 PM Ferruh Yigit wrote:
> > I'm incredibly frustrated with this whole process to be honest...
>
> Please don't be so, you are spending time/effort to improve an open source
> project which is great, thank you again.
>
> Why don't we take this as incremental steps, first
On Wed, Oct 10, 2018 at 2:25 PM Ferruh Yigit wrote:
>
> On 9/4/2018 1:36 AM, Dan Gora wrote:
> > Hi Ferruh,
> >
> > I remembered now the motivation behind separating rte_kni_release()
> > and rte_kni_free().
> >
> > The problem is that the DPDK thread whi
On Wed, Oct 10, 2018 at 11:16 AM Ferruh Yigit wrote:
>
> On 9/27/2018 1:32 AM, Dan Gora wrote:
> > Hi All,
> >
> > Attached is version 3 of a patchset to add a new API function to
> > set the link status on kernel interfaces created with the KNI kernel
> > m
On Wed, Oct 10, 2018 at 11:09 AM Ferruh Yigit wrote:
> > Yes, I understand that.. As I pointed out previously, if there is no
> > physical device which corresponds to this KNI interface, the
> > application can:
> >
> > 1) Not use this API at all, just as they do now.
>
> This API has nothing wit
On Fri, Sep 28, 2018 at 5:03 AM Ferruh Yigit wrote:
>
> On 9/28/2018 12:51 AM, Dan Gora wrote:
> > On Thu, Sep 27, 2018 at 8:44 PM, Ferruh Yigit
> > wrote:
> >>> Well, yes the link_status (link up, link down) _is_ applied to the KNI
> >>> interface.
On Thu, Sep 27, 2018 at 8:44 PM, Ferruh Yigit wrote:
>> Well, yes the link_status (link up, link down) _is_ applied to the KNI
>> interface. When that occurs, most people want to know what the link
>> speed is that the link came up at.
>
> +1 to this, people would like to know link speed of the i
On Thu, Sep 27, 2018 at 6:49 PM, Ferruh Yigit wrote:
>>> It would be useful if it writes the values of virtual interface, but this
>>> API
>>> prints user input.
>>>
>> I'm sorry, Ferruh, I really don't understand what you are referring to
>> here. What virtual interface are you talking about?
>
On Thu, Sep 27, 2018 at 7:04 PM, Ferruh Yigit wrote:
>>
>> With no traffic it's worse because the worker threads perform these
>> increments even more often!
>
> Dear Dan,
>
> Your implementation doesn't prevent the race when there is traffic, it can be
Correct. To do that would require per-cpu
On Thu, Sep 27, 2018 at 8:40 AM Ferruh Yigit wrote:
> >> Not sure about introducing an extra check to datapath for possible error on
> >> stats zero. I am for dropping this patch, what do you think?
> >
> > This is literally adding one instruction to the datapath. Not even an
> > atomic instructi
On Thu, Sep 27, 2018 at 8:35 AM Ferruh Yigit wrote:
>
> On 9/26/2018 7:56 PM, Dan Gora wrote:
> > On Wed, Sep 26, 2018 at 1:42 PM, Ferruh Yigit
> > wrote:
> >>> There is nothing to "reflect" to the kernel interface, nor to apply to
> >>> th
Add logging messages showing the commands necessary for the user to
have the application display and zero the statistics.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/examples/kni/main.c b/examples/kni
Test changing the link, speed, duplex, etc. status of the KNI interface
with rte_kni_update_link().
Signed-off-by: Dan Gora
---
test/test/test_kni.c | 131 +++
1 file changed, 131 insertions(+)
diff --git a/test/test/test_kni.c b/test/test/test_kni.c
rx/tx_packets
in worker threads by a non-zero amount. This limits the race to the
periods in which traffic is actually being received or transmitted.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/examples/kni/main.c b
Set the carrier state to 'off' when the interface is instantiated
or when it is marked 'up' or 'down'. This is necessary to set the
interface to a known operational state until the carrier state is
changed with rte_kni_update_link().
Signed-off-by: Dan Gora
---
k
Update KNI example to continuously monitor the Ethernet link status
of the physical link and update the link status of the corresponding
interfaces with rte_kni_update_link().
Signed-off-by: Dan Gora
---
examples/kni/Makefile | 2 ++
examples/kni/main.c | 73
Add a new API function to KNI, rte_kni_update_link() to allow DPDK
applications to update the link status for KNI network interfaces in
the linux kernel.
Signed-off-by: Dan Gora
---
lib/librte_kni/rte_kni.c | 57 ++
lib/librte_kni/rte_kni.h | 18
kni_version.map to the bottom of
> the patch file, it doesn't complain any more... I just don't really
> have time to investigate this right now.
thanks
dan
Dan Gora (6):
kni: add API to set link status on kernel interface
kni: add link status test
kni: set default ca
On Wed, Sep 26, 2018 at 11:00 AM, Ferruh Yigit wrote:
> On 9/19/2018 8:55 PM, Dan Gora wrote:
>> Update KNI example to continuously monitor the Ethernet link status of
>> the physical link and update the carrier status of the corresponding
>> interfaces with rte_kni_update
On Wed, Sep 26, 2018 at 1:42 PM, Ferruh Yigit wrote:
>> There is nothing to "reflect" to the kernel interface, nor to apply to
>> the kernel interface. This is exactly how every other kernel driver
>> works on link status changes. There is no "netif_set_speed()'
>> function. When a link status
On Wed, Sep 26, 2018 at 10:59 AM, Ferruh Yigit wrote:
> On 9/19/2018 8:55 PM, Dan Gora wrote:
>> Add a new API function to KNI, rte_kni_update_link() to allow DPDK
>> applications to update the link status for KNI network interfaces in
>> the linux kernel.
>>
On Wed, Sep 26, 2018 at 11:01 AM, Ferruh Yigit wrote:
> On 9/19/2018 8:55 PM, Dan Gora wrote:
>> The worker threads incrementing the rx/tx_packets race with the signal
>> handler from the main thread zeroing the entire statistics structure.
>> This can cause the statistics
rx/tx_packets
in worker threads by a non-zero amount. This limits the race to the
periods in which traffic is actually being received or transmitted.
Signed-off-by: Dan Gora
---
examples/kni/main.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/examples/kni/main.c b
Update KNI example to continuously monitor the Ethernet link status of
the physical link and update the carrier status of the corresponding
interfaces with rte_kni_update_link().
Signed-off-by: Dan Gora
---
examples/kni/Makefile | 2 ++
examples/kni/main.c | 82
1 - 100 of 171 matches
Mail list logo
