is bysy" easily.
(I admit relatively rough measurement though. I think it is trade-off)
What do you think?
Thanks!
BR,
Hideyuki Yamashita
NTT TechnoCross
> > -Original Message-
> > From: dev On Behalf Of David Hunt
> > Sent: Friday, December 4, 2020 3:51 PM
> &
Hello,
Sorry about the following.
I typo in email address in "signed-off-by".
I will revise it in the upcoming revised patchset.
Sorry!
BR,
Hideyuki Yamashita
NTT TechnoCross
> Look like I am facing `mail delivery` issues to `ntt-tx.co.jp`.
>
> ```
> The fol
Hello,
Thanks for your feedback.
> On Fri, 04 Dec 2020 16:51:09 +0900
> Hideyuki Yamashita wrote:
>
> > +
> > +/* Macros for printing using RTE_LOG */
> > +#define RTE_LOGTYPE_APISTATS RTE_LOGTYPE_USER1
> > +
>
> Please don't use static logtypes.
Hello,
Thanks for your comments.
Please see my comments inline tagged with [HY].
> Hi,
>
> >
> > This patch modifies to use apistats by librte_ethdev.
> >
> > Signed-off-by: Hideyuki Yamashita
> > ---
> > lib/librte_ethdev/meson.build| 6 ++-
Hello,
Thanks for your comments.
Please see my comments inline tagged with [HY].
> Hi,
>
> >
> > This patch modifies to use apistats by librte_ethdev.
> >
> > Signed-off-by: Hideyuki Yamashita
> > ---
> > lib/librte_ethdev/meson.build| 6 ++-
Hello,
Thanks for your comments.
Please see my comments inline tagged with [HY].
> 04/12/2020 08:51, Hideyuki Yamashita:
> > In general, DPDK application consumes CPU usage because it polls
> > incoming packets using rx_burst API in infinite loop.
> > This makes difficult
Hi, David
Thanks for your comments.
Please see my comments inline tagged with [HY].
>
> On 4/12/2020 7:51 AM, Hideyuki Yamashita wrote:
> > In general, DPDK application consumes CPU usage because it polls
> > incoming packets using rx_burst API in infinite loop.
> >
This patch modifies to use apistats by librte_ethdev.
Signed-off-by: Hideyuki Yamashita
---
lib/librte_ethdev/meson.build| 6 ++-
lib/librte_ethdev/rte_apistats.c | 64
lib/librte_ethdev/rte_apistats.h | 64
lib
This patch modifies document of proc-info to introduce "--apistats"
parameter.
Signed-off-by: Hideyuki Yamashita
---
doc/guides/tools/proc_info.rst | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/doc/guides/tools/proc_info.rst b/doc/guides/tools/pro
This patch modifies to use apistats by testpmd app.
- change on testpmd.c to call apistats functions to accumlate stats info
Signed-off-by: Hideyuki Yamashita
---
app/test-pmd/testpmd.c | 4
1 file changed, 4 insertions(+)
diff --git a/app/test-pmd/testpmd.c b/app/test-pmd/testpmd.c
index
This patch modifies to use apistats by proc-info app.
- change on main.c to call apistats functions
- change on Makefile to include experimental API
Signed-off-by: Hideyuki Yamashita
---
app/proc-info/main.c | 46
1 file changed, 46 insertions
This patch adds maintainer of rte_apistats.c and rte_apistats.h.
Signed-off-by: Hideyuki Yamashita
---
MAINTAINERS | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index eafe9f8..dba2acf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -489,6 +489,9 @@ F: drivers
proc-info to retrieve above mentioned counter information
- add description in proc-info document about --apistats parameter
- modify MAINTAINERS file for apistats.c and apistats.h
Hideyuki Yamashita (5):
maintainers: update maintainers file for apistats
app/proc-info: add to use apistats
app
Hello,
I am planning to propose patch for
optional feature.
Question:
Where should I write compile switch for
optional features?
I was planning to add flag to enable
optional festures into config/common_base
like following:
+#
+# Compile the api statistics library
+#
+CONFIG_RTE_LIBRTE_APIST
nhancement.
(measure cpu usage)
I think it is good.
Anyway I will start preparing patch itself first
and want to hear "how others think about my idea/proposal".
Thanks!
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi,
>
> The way we do this accounting is completely different, it depend
Hello Morten,
Thanks for your giving me your valuable feedback.
Please see inline tagged with [Hideyuki].
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Hideyuki Yamashita
> > Sent: Wednesday, November 25, 2020 6:40 AM
> >
> > Hello,
> >
> > Foll
.
--
Thank you,
Hideyuki Yamashita
NTT TechnoCross
Hello Matan and Slava,
Thanks for your quick response.
How about the following?
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hello Matan and Slava,
>
> Thanks for your quick response.
>
> 1. What you were saying is correct.
> When I create flow with dst mac 10:22:33:44:55:66
Hello Matan and Slava,
Thanks for your quick response.
How about the following?
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hello Matan and Slava,
>
> Thanks for your quick response.
>
> 1. What you were saying is correct.
> When I create flow with dst mac 10:22:33:44:55:66
default handling.
Thanks!
Best Regards,
Hideyuki Yamashita
NTT TechnoCross
> Hi
>
> This bit on in dst mac address = "01:00:00:00:00:00" means the packets is L2
> multicast packet.
>
> When you run Testpmd application the multicast configuration is forwarded to
>
t_ip)/ICMP()
pkt.show()
sendpfast(pkt, iface=iface, pps=pps, loop=loop, file_cache=True)
icmp_send()
-----
Thanks!
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi, Hideyuki
>
> The frame in your report is broadcast/
Hello Slava,
Note that I am using the following dpdk rc.
DPDK 19.11 rc-1
BR,
HIdeyuki Yamashita
NTT TechnoCross
> Hello Slava,
>
> As I reported to you, creating flow was successful with Connect-X5.
> However when I sent packets to the NIC from outer side of
> the host,
port=0
Other packet(VLAN101 packet) discarded.
Expectation:
Matched packet queued to queue =1, port=0
Non Matched packet queued to queue=0, port=0
Question:
Is above behavior collect?
What is the default behavior of unmatchedd packets (queue to queue=0 or
discard packet)
BR,
Hideyuki Yamashi
tpmd> flow create 0 egress group 0 pattern eth / end actions jump group 1
Bad arguments
testpmd> flow create 0 egress group 0 pattern eth / end actions jump group 1 /
end
Flow rule #1 created
In short, my questions resolved!
Thanks!
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi, Hideyuki
>
flow for entag VLAN tag on not-tagged packet)
Thanks again.
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi, Hideyuki
>
> > -Original Message-
> > From: Hideyuki Yamashita
> > Sent: Wednesday, November 6, 2019 13:04
> > To: Slava Ovsiienko
> > Cc: dev
change will be mergerd and
available?
BR,
Hideyuki Yamashita
NTT TechnoCross
> Dear Slava,
>
> Thanks for your response.
>
> Inputting other flows failed while some flows are created.
> Please help on the following two cases.
>
> 1) I would like to detag vlan tag which h
(specific action): cause: 0x7ffdc9d98348, match on VLAN is
required in order to set VLAN VID: Invalid argument
Thanks!
BR,
Hideyuki Yamashita
NTT TechnoCross
> > -Original Message-
> > From: Hideyuki Yamashita
> > Sent: Thursday, October 31, 2019 11:52
> > To: Slav
ity 0 pattern eth dst is
00:16:3e:2 e:7b:6a / vlan vid is 1480 / end actions of_pop_vlan /
queue index 0 / end
Flow rule #0 created
testpmd>
--
BR,
Hideyuki Yamashita
NTT Tec
(cause unspecified): cannot create table: Cannot allocate
memory
BR,
Hideyuki Yamashita
amp;ssn=u44h3rn8ngcmbdl6v0fvhqrgt3
Do you have any hints?
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi, Hideyuki.
>
> Thanks for providing extra information.
>
> We rechecked the VLAN actions support in OFED 4.7.1, it should be supported.
> There are some limitations:
> - VLAN
priv-flags: yes
If you needs more info from my side, please let me know.
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi, Hideyuki
>
> > -Original Message-----
> > From: Hideyuki Yamashita
> > Sent: Monday, October 21, 2019 10:12
> > To: Hideyuki Yamashita
> >
Dear Slava, Moti and all,
Please let me know if you need more information.
Partial answer is acceptable for me.
Thanks in advaince!
BR,
HIdeyuki Yamashita
NTT TechnoCross
> Dear Slava and experts,
>
> Thanks for your answering me.
> Baased on your answer, I tested using testpmd.
mehow wrong.
Q2. Is it correct understanding that "egress" is not supported for mlx5 PMD?
Q3. If yes, is it possible to entag VLAN tag to the outgoing packet from
physical NIC by using rte_flow?
BR,
Hideyuki Yamashita
NTT TechnoCross
> > -Original Message-
> > From: H
ag VLAN 101 to the traffic from VM to PHY:0 is it possible?)
>
> Thanks in advance!
>
> BR,
> Hideyuki Yamashita
> NTT TechnoCross
>
> > VLAN actions support is implemented in librte_ethdev, and in
> > test-pmd application, based on [1] Generic flow API.
> >
apply rte_flow actions for specified tx queue
of physical NIC?
(e.g. VM connect with PHY:0 using tx queue index:1, I want
to entag VLAN 101 to the traffic from VM to PHY:0 is it possible?)
Thanks in advance!
BR,
Hideyuki Yamashita
NTT TechnoCross
> VLAN actions support is implemented
Hello Ye,
Thanks for your quick response.
I understand the basis.
I don't have much intention to push proposal to 19.11
right now.
Thanks again.
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi,
>
> On 08/09, Hideyuki Yamashita wrote:
> >Hello Experts,
> >
> >
t;git clone" ?
Or tar ball of previous version like "dpdk-19.05.tar.gz"?
Q2.
If review of the patch starts around October, when
will the patch will be merged, if patch is good one.
19.11 LTS? or 20.02?
(Are there any rule or deadlines?)
Thanks in advance,
Hideyuki Yamashita
NTT TechnoCross
> On Tue, Dec 18, 2018 at 08:30:16PM +0900, Hideyuki Yamashita wrote:
> > > On Tue, Dec 18, 2018 at 02:52:16PM +0900, Hideyuki Yamashita wrote:
> > > > > On Tue, Dec 18, 2018 at 12:11:33PM +0900, Hideyuki Yamashita wrote:
> > > > > >
> > > &
The common data freeing has been moved to rte_eth_dev_release_port(),
so freeing mac_addrs like this in eth_dev_close() is unnecessary and
will cause double free.
Fixes: e16adf08e54d ("ethdev: free all common data when releasing port")
Cc: sta...@dpdk.org
Signed-off-by: Hideyuki
> On Tue, Dec 18, 2018 at 02:52:16PM +0900, Hideyuki Yamashita wrote:
> > > On Tue, Dec 18, 2018 at 12:11:33PM +0900, Hideyuki Yamashita wrote:
> > > >
> > > > On Mon, Dec 17, 2018 at 11:21:01AM +, Burakov, Anatoly wrote:
> > > > >
From: Hideyuki Yamashita
When rte_dev_remove is called for vhost, eth_dev_close and
rte_eth_dev_release_port is called.
Both eth_dev_close and rte_eth_dev_release_port calls rte_free
for same data area(mac_addrs) and thus causes double free.
This patch fixes this by deleting rte_free for
> On Tue, Dec 18, 2018 at 12:11:33PM +0900, Hideyuki Yamashita wrote:
> >
> > On Mon, Dec 17, 2018 at 11:21:01AM +, Burakov, Anatoly wrote:
> > > > On 17-Dec-18 10:45 AM, Hideyuki Yamashita wrote:
> > > > > > On 17-Dec-18 10:02 AM, Hideyuki Yamas
> On Mon, Dec 17, 2018 at
11:21:01AM +, Burakov, Anatoly wrote:
> > On 17-Dec-18 10:45 AM, Hideyuki Yamashita wrote:
> > > > On 17-Dec-18 10:02 AM, Hideyuki Yamashita wrote:
> > > > > Dear Thomas and all,
&
> On 17-Dec-18 10:45 AM, Hideyuki Yamashita wrote:
> >> On 17-Dec-18 10:02 AM, Hideyuki Yamashita wrote:
> >>> Dear Thomas and all,
> >>>
> >>> I took a look on dpdk code.
> >>> I firstly write qustions and my analisys
> >>&g
> On 17-Dec-18 10:23 AM, Burakov, Anatoly wrote:
> > On 17-Dec-18 10:02 AM, Hideyuki Yamashita wrote:
> >> Dear Thomas and all,
> >>
> >> I took a look on dpdk code.
> >> I firstly write qustions and my analisys
> >> on the current dpdk code f
> On 17-Dec-18 10:02 AM, Hideyuki Yamashita wrote:
> > Dear Thomas and all,
> >
> > I took a look on dpdk code.
> > I firstly write qustions and my analisys
> > on the current dpdk code follows after that.
> >
> > [1.Questions]
> > I have seve
lloc_heap_free(malloc_elem_from_data(addr)) < 0)
RTE_LOG(ERR, EAL, "Error: Invalid memory\n");
}
encounter the error.
As an experiment, I commented out one of them, "ERR, Invalid memory"
disappered.
Thanks and BR,
Hideyuki Yamashita
NTT TechnoCross
> Adding my c
Adding my colleague Yasufumi and Hiroyuki as CC.
We are waiting valuable advice from you.
Thanks in advance,
Hideyuki Yamashita
NTT TechnoCross
>
> Dear Thomas and all,
>
> I hope you all get safely back home after DPDK summit.
> (When I get back Japan, it is chilling. (
?
Thanks in advance and have a nice day.
BR,
Hideyuki Yamashita
NTT TechnoCross
NOT "opt-in" "opt-out" feature.
When considering many NFV applications are already
there, I think it is more preferable that such statistics features
can be "opt-in" or "opt-out".
Is it possible to realize above using current DPDK framework?
Thanks again.
BR,
Hideyuki Yamashita
NTT TechnoCross
> Regards,
> Rami Rosen
Hello Kevin,
Thanks for your answering.
Please see inline tagged with [Hideyuki].
> On 21/11/2018 11:38, Ferruh Yigit wrote:
> > On 11/21/2018 7:48 AM, Hideyuki Yamashita wrote:
> >> Hello,
> >>
> >> I have some basic questions about telemetry API
> >
ample only use 'telemetry' though.)
Have a nice day and thanks again.
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi Hideyuki,
>
> Regarding your questions about DPDK CPU usage, etc:
> I believe that due to the way PMDs are implemented, maybe one
> should consider us
ove is that
- I am relative new to DPDK world and have almost no knowledge about
"telemetry"
- I am interested in how dpdk applications can "scales" on platform
like OpenStack. I think some mesurement mechanism required
and I thought it might be "telemetry" APIs.
Thanks in advance.
BR,
Hideyuki Yamashita
NTT TechnoCross
Hi
Thanks for your answering to my question.
Please see inline.
> Hi, Hideyuki Yamashita
>
>
> > -Original Message-
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Hideyuki Yamashita
> > Sent: Wednesday, October 31, 2018 4:22 PM
> > To: de
driver does not support jumbo frame.
Q1. Is my understanding above correct?
Q2. If A1 equals YES, then are there any future plan to support
jumbo frame on ixgbe?
BR,
Hideyuki Yamashita
NTT TechnoCross
Hi,
> 25/10/2018 04:54, Hideyuki Yamashita:
> > Hi,
> >
> > > Yes it may work with most of the drivers.
> > Question for my understadnding.
> > You said that most of the drivers assign only one
> > port when hotplug_add is called, right?
> > The
pmd
- null pmd
and I understand those device(?) assign only one port per attach.
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi,
>
> 23/10/2018 03:52, Hideyuki Yamashita:
> > Hi,
> >
> > Thanks for your guidance again.
> >
> > Q1.
> > Is followi
t_port_by_name" with regard
to handle devices which create multiple port.
But I need to replace existing deprecated attach/detach APIs to new
codes to maintain continuity of my product.
BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi,
>
> The better approach is using RTE_ETH_FOREACH_MAT
s the difference" and "which is better approach".
Thanks and BR,
Hideyuki Yamashita
NTT TechnoCross
> Hi,
>
> I am actively working on it.
> Look how rte_eth_dev_attach is replaced in testpmd:
> https://patches.dpdk.org/patch/47019/
> It is using a new ethdev
)
return ret;
-
If you have any concerns/additional advices, please let me know.
BR,
Hideyuki Yamashita
NTT TechnoCross
> 27/09/2018 12:40, Hideyuki Yamashita:
> > Dear Thomas,
> >
> > Thansk for your answer.
&
Dear Thomas,
Thansk for your answer.
Please see inline.
> 27/09/2018 03:38, Hideyuki Yamashita:
> > Dear Thomas,
> >
> > Thanks for your answer.
> > It took me a little time to digest answer.
> > Please see inline.
> >
> >
> > > 21/09/2
Dear Thomas,
Thanks for your answer.
It took me a little time to digest answer.
Please see inline.
> 21/09/2018 09:19, Hideyuki Yamashita:
> > Dear Gaetan and Thomas,
> >
> > Thanks for your answer.
> > Please see inline.
> >
> > > 20/09/2018 11:09,
Dear Gaetan and Thomas,
Thanks for your answer.
Please see inline.
> 20/09/2018 11:09, Ga枓an Rivet:
> > On Thu, Sep 20, 2018 at 05:46:37PM +0900, Hideyuki Yamashita wrote:
> > > Hello,
> > >
> > > From dpdk 18.08 release rte_eth_dev_attach and
> > >
Your advice/guidance are much appreciated.
Thanks!
BR,
Hideyuki Yamashita
-
Hideyuki Yamashita
NTT TechnoCross
-
64 matches
Mail list logo
