On Mon, Jun 26, 2023 at 10:57 PM Simon Horman wrote:
>
> On Fri, Oct 09, 2020 at 08:15:03PM +0800, hepeng.0320 wrote:
> > when running ovs-tcpdump -i ethX and the port is used as the incomming port
> > for a vxlan port.
> >
> > The callstack for the upcall:
> >
> > mirror_ingress_packet
> >
for this
> inconsistence, and would like to hear your “new cause”.
>
>
>
> Anyway I believe your below patch should fix this issue.
>
> [ovs-dev,ovs-dev,v2,1/4] ofproto-dpif-upcall: fix push_dp_ops
>
>
>
> Br,
>
> Zhike
>
>
>
> *From: *".贺
cause for that, but due to this complex race between PMD
and revalidator, I wish this time I am right.
But before that, why are you interested in this patch? Have you found the
same issue in your environment?
On Thu, Sep 22, 2022 at 6:54 PM .贺鹏 wrote:
> Hi, zhike,
>
> It's difficul
Hi, zhike,
It's difficult to give a very clear sequences about how this inconsistency
happens, but I can give you more details.
This is observed in our production environment. The correct megaflow should
encap packets with vxlan header and send out, but the action is drop.
This is usually
On Tue, Feb 15, 2022 at 2:10 AM Ilya Maximets wrote:
>
> On 1/28/22 17:14, Aaron Conole wrote:
> > From: Peng He
> >
> > ipf_postprocess will emit packets into the datapath pipeline ignoring
> > the conntrack context, this might casuse weird issues when a packet
> > batch has less space to hold
Ah,
found a bug, will submit a v4.
Peng He 于2022年1月18日周二 21:08写道：
> From hepeng:
>
> https://patchwork.ozlabs.org/project/openvswitch/patch/20200717015041.82746-1-hepeng.0...@bytedance.com/#2487473
>
> also from guohongzhi :
>
>
Hi， yunjian and Ilya,
this patch reminds me of the discussion we have in March last year, and
during the discussion, you have spotted this
thread-safety issue of uuid map. Unfortunately, in that email, you did not
reply to the mailist, so I cannot give a link to
the email. I attach it as a
Hi, Harold,
I am curious how this bug is found as I have an unsolved bug that I believe
it's related to
some memory issues and may be related to NIC's problem.
Harold Huang 于2022年1月13日周四 16:24写道：
> From: Harold Huang
>
> When one flow is output to multiple egress ports, OVS copy the packets
Hi,
this patch can pass all the system-userspace testsuite if one of my another
patch
gets merged.
So maybe review this patch "[ovs-dev] ofproto-dpif: fix
packet_execute_prepare" first.
Peng He 于2022年1月18日周二 11:28写道：
> From: Peng He
>
> ipf_postprocess will emit packets into the datapath
Hi,
Thanks for the reviewing.
Aaron Conole 于2022年1月12日周三 05:37写道：
> Peng He writes:
>
> > by using ipf_list's key instead of first frags' metadata can reduce
> > quite a lot of cache access as by the time calling ipf_ctx_eq, ipf_list
> > is cache-hot.
> >
> > Signed-off-by: Peng He
> > ---
>
Hi,
after I applied this patch, all the failed tests now passed.
diff --git a/ofproto/ofproto-dpif.c b/ofproto/ofproto-dpif.c
index cba49a99e..a7df7db6f 100644
--- a/ofproto/ofproto-dpif.c
+++ b/ofproto/ofproto-dpif.c
@@ -4972,6 +4972,7 @@ packet_execute_prepare(struct ofproto *ofproto_,
just forget to reply all.
-- Forwarded message -
发件人： 贺鹏
Date: 2022年1月9日周日 10:59
Subject: Re: [ovs-dev v6 3/3] ipf: ipf_preprocess_conntrack should also
consider ipf_ctx
To: Mike Pattrick
Hi, Mike,
thank you for the review and testing.
it seems that all these broken tests
Hi, Mike,
The bug in the last email is not correct.
in packet_execute_prepare functions,
it has changed dp_packet md's port into the odp port,
but in the execute->flow, the value is still the ofp port.
static void
packet_execute_prepare(struct ofproto *ofproto_,
I have found another problem in the ipf code which is related to the ipf.
will send a new version consists of two patches.
Mike Pattrick 于2021年11月30日周二 05:08写道：
> Looks good to me!
>
> Acked-by: Mike Pattrick
>
>
> On Sat, 2021-11-27 at 03:39 +, Peng He wrote:
> > From: Peng He
> >
> >
Hi, Paolo
well done.
the patch looks good to me.
and I am going through your other patches.
I wonder maybe finally we need a *conn_flags* to store all the informations
containing NAT, cleaned flag, etc.
Paolo Valerio 于2021年11月30日周二 02:06写道：
> From: Peng He
>
> Currently, when doing NAT,
Ah, in the commits, I forget to delete the introduction of recirc_depth.
will send a v5.
0-day Robot 于2021年11月20日周六 下午6:20写道：
> Bleep bloop. Greetings Peng He, I am a robot and I have tried out your
> patch.
> Thanks for your contribution.
>
> I encountered some error that I wasn't expecting.
Hi, Michael,
thanks for the suggestion!
the patch looks good to me, did you do the test in the patch?
Mike Pattrick 于2021年11月18日周四 上午6:33写道：
> Hello Peng,
>
> Great patch! How do you feel about a patch like this to get away from
> recursion?
>
> diff --git a/lib/dpif-netdev.c
Hi,
One recirc_id can be viewed as a frozen state in the "xlate" process
and this frozen state stores tunnel info in it. So this recirc_id can also
be viewed as a packet tag, with this tag it means the packet has all
the tunnel metadata.
So I was wondering if the "xlate" process sees a packets
Sure,
will send a v2. Thanks for the review.
Ilya Maximets 于2021年7月26日周一 上午7:22写道：
>
> Re-adding the list and people from CC.
>
> On 6/27/21 8:16 AM, 贺鹏 wrote:
> > Hi, Ilya,
> >
> > sorry for replying so late, being really busy this month.
>
> Busy time
Hi,
friendly ping for this patch.
Ilya Maximets 于2021年5月22日周六 上午3:50写道：
>
> On 5/21/21 5:00 AM, 贺鹏 wrote:
> > Hi, Ilya
> >
> >
> >
> > Ilya Maximets 于2021年5月19日周三 下午8:50写道：
> >>
> >> On 2/27/21 10:34 AM, Peng He wrote:
> >>>
Great, thanks!
Ben Pfaff 于2021年6月29日周二 下午11:36写道：
>
> On Tue, Jun 29, 2021 at 09:49:39PM +0800, 贺鹏 wrote:
> > I am investigating the OVS RCU code, and feel confused about the
> > perthread->mutex, what's the usage of this mutex? it seems in the code
> > ther
Hi,
I am investigating the code of revalidator and the DPDK netdev
datapath for OVS.
I have some questions:
1) why save a whole flow in the dp_nedev_key? Currently, the size of
flow is around 670 bytes, and the full size of dp_netdev_key is around
1500 (meaning that this flow takes 50% of the
-- 转发的邮件 --
发件人： *贺鹏*
日期： 2021年6月29日星期二
主题： "Why perthread->mutex is needed?"
收件人： Sriharsha Basavapatna via dev , Ben Pfaff <
b...@ovn.org>
Hi，Ben,
I am investigating the OVS RCU code, and feel confused about the
perthread->mutex, what's the usage o
Hi，Ben,
I am investigating the OVS RCU code, and feel confused about the
perthread->mutex, what's the usage of this mutex? it seems in the code
there are only codes that inits and destroys the mutex, but there is
no code that locks and unlocks it.
Thanks.
--
hepeng
Hi, Ilya
Ilya Maximets 于2021年5月19日周三 下午8:50写道：
>
> On 2/27/21 10:34 AM, Peng He wrote:
> > CT zone could be set from a field that is not included in frozen
> > metadata. Consider the example rules which are typically seen in
> > OpenStack security group rules:
> >
> >
Hi,
If you have time to rework it then it's great. You can put me as one
of the authors using the bytedance email address (as an obligation of
the company policy).
Thanks.
Gaëtan Rivet 于2021年5月7日周五 下午5:26写道：
>
> On Sat, Mar 6, 2021, at 03:44, 贺鹏 wrote:
> > Gaëtan Rivet 于2021年3月2日
Hi,
it has been two months now, can anyone review this patch?
贺鹏 于2021年3月19日周五 下午4:42写道：
>
> Hi,
>
> Ping for this patch.
>
> 贺鹏 于2021年3月6日周六 上午10:37写道：
> >
> > Mark Gray 于2021年3月5日周五 下午7:54写道：
> > >
> > > On 27/02/2021 09:34, Peng He
Hi,
Ping for this patch.
贺鹏 于2021年3月6日周六 上午10:37写道：
>
> Mark Gray 于2021年3月5日周五 下午7:54写道：
> >
> > On 27/02/2021 09:34, Peng He wrote:
> > > CT zone could be set from a field that is not included in frozen
> > > metadata. Consider the example rules which a
Is this a version that mixes using refcount and RCU?
do we have reached an agreement?
BTW, please use my company email address: hepeng.0...@bytedance.com
thanks.
Hongzhi Guo 于2021年3月8日周一 上午11:34写道：
>
> ASAN report use-after-free of ofproto when destroy ofproto_rule.
> The rule uses both RCU
Gaëtan Rivet 于2021年3月3日周三 上午4:01写道：
>
> On Sun, Nov 29, 2020, at 03:32, hepeng.0320 wrote:
> > From: hepeng
> >
> > This patch tries to use ovs_spin_lock as an alternative to reduce the
> > size of each conn. The ovs_mutex_lock consumes 48 bytes while the
> > ovs_spin_lock only uses 16 bytes.
>
Gaëtan Rivet 于2021年3月3日周三 上午3:49写道：
>
> On Sun, Nov 29, 2020, at 03:32, hepeng.0320 wrote:
> > From: hepeng
> >
> > Just like the previous patch, split the handle_ftp_ctl into
> > handle_ftp_interest and handle_ftp_other, since we can infer
> > which one to call from the called positions.
> >
>
Gaëtan Rivet 于2021年3月3日周三 上午1:46写道：
>
> On Sat, Feb 27, 2021, at 09:49, 贺鹏 wrote:
> > Hi,
> >
> > Thanks for the detailed reviews.
> > These patches are like RFC to see if the work is interesting enough.
> >
> > Aaron Conole 于2021年2月25日周四 上
Hi,
I've read all your suggestions and appreciate that.
Just have been through a very busy week, and probably will have a
very busy month, so the work and reply might be slow.
Will do a rebase in the next version.
I've seen some of your patches related to CT. do you have some plans
for CT
Mark Gray 于2021年3月5日周五 下午7:54写道：
>
> On 27/02/2021 09:34, Peng He wrote:
> > CT zone could be set from a field that is not included in frozen
> > metadata. Consider the example rules which are typically seen in
> > OpenStack security group rules:
> >
> >
On Tue, Mar 2, 2021 at 4:15 AM Ilya Maximets wrote:
>
> On 2/27/21 9:53 AM, 贺鹏 wrote:
> > Hi,
> >
> > Thanks William and Ilya for a detailed revisiting of the origin of the
> > problem. I learned a lot.
> >
> > I now understand that the mix usin
Hi,
Thanks for the detailed reviews.
These patches are like RFC to see if the work is interesting enough.
Aaron Conole 于2021年2月25日周四 上午1:37写道：
>
> "hepeng.0320" writes:
>
> > From: hepeng
> >
> > Currently, when doing NAT, the userspace conntrack will use an extra
> > conn for the two
Hi,
Sent a new version of the patch.
贺鹏 于2021年2月20日周六 上午10:21写道：
>
> Hi, Mark,
>
> thanks for the review!
>
> Mark Gray 于2021年2月19日周五 下午9:07写道：
> >
> > On 18/02/2021 09:43, Peng He wrote:
> >
> > One small comment below. By the way, good catch ..
Hi,
Thanks William and Ilya for a detailed revisiting of the origin of the
problem. I learned a lot.
I now understand that the mix using of RCU and refcounts is not
intended in the first place.
But my point is that mix using RCU and refcounts now gives you more
choices, and actually eases the
Ilya Maximets 于2021年2月25日周四 上午12:01写道：
>
> On 2/24/21 3:29 PM, Ilya Maximets wrote:
> > On 7/17/20 3:50 AM, hepeng.0320 wrote:
> >> From: Peng He
> >>
> >> The call stack of rule_destroy_cb:
> >>
> >> remove_rules_postponed (one grace period)
> >> -> remove_rule_rcu
> >> ->
Hi, Ilya and William,
Ilya Maximets 于2021年2月22日周一 下午8:12写道：
>
> On 2/21/21 5:11 PM, William Tu wrote:
> > On Fri, Feb 19, 2021 at 6:29 PM 贺鹏 wrote:
> >>
> >> Hi, Ilya
> >>
> >> Ilya Maximets 于2021年2月19日周五 下午7:19写道：
> >>>
> >&g
Hi, Ilya
Ilya Maximets 于2021年2月19日周五 下午7:19写道：
>
> On 2/19/21 3:12 AM, 贺鹏 wrote:
> > Hi,
> >
> > Looks like this bug is caused by violating the fact that if a rule is
> > referenced, the related ofproto should not be destroyed.
> >
> > If so, I have a p
Hi, Mark,
thanks for the review!
Mark Gray 于2021年2月19日周五 下午9:07写道：
>
> On 18/02/2021 09:43, Peng He wrote:
>
> One small comment below. By the way, good catch .. i found it difficult
> enough to review it, let alone find it!
Thanks.
This is found by exploring our controller's bug, which
Hi,
Looks like this bug is caused by violating the fact that if a rule is
referenced, the related ofproto should not be destroyed.
If so, I have a patch that also fixes the problem, not sure if this helps.
Hi, I've already sent a v2 patch.
Mark Gray 于2021年2月17日周三 下午6:44写道：
>
> On 17/02/2021 10:40, 贺鹏 wrote:
> > Hi,
> >
> > Thanks for the review.
> >
> > Mark Gray 于2021年2月17日周三 下午6:13写道：
> >>
> >> I'm not too familiar with this code but I have
Hi,
Thanks for the review.
Mark Gray 于2021年2月17日周三 下午6:13写道：
>
> I'm not too familiar with this code but I have some comments.
>
> On 15/02/2021 09:50, Peng He wrote:
> > CT zone could be set from a field that is not included in frozen
> > metedata. Consider the belowing cases which is normally
ping
于2020年10月14日星期三 11:15 写道:
if there are multiple pkts in the batch, the loop will access a freed rp,
which cause ovs crash. --- lib/ipf.c | 3 ++- 1 file changed, 2
insertions(+), 1 deletion(-) diff --git a/lib/ipf.c b/lib/ipf.c index
446e89d13..c20bcc0b3 100644 --- a/lib/ipf.c +++
sorry, please ignore this patch.
hepeng.0320 于2020年10月9日周五 下午8:36写道：
>
> From: Peng He
>
> if for some reason, the dpif ops in push_dp_ops failed with op->dop.type
> not equal to DPIF_OP_FLOW_DEL, the generated ukey is installed however
> the corresponding datapath flow is not. The consequent
yes，check dpdk gso lib……
在 2020年3月10日星期二，txfh2007 via dev 写道：
> Hi Flavio and all:
>
> Is there a way to support software TSO for DPDK tunnel network ? I
> have tried userspace TSO function, and running on tunnel network, I have
> got the following error:
> "Tunneling packets with HW
ignore this patch, forget to sign-off the patch.
hepeng.0320 于2020年5月22日周五 下午5:02写道：
>
> when running ovs-tcpdump -i ethX and the port is used as the incomming port
> for a vxlan port.
>
> The callstack for the upcall:
>
> mirror_ingress_packet
> mirror_packet
> output_normal
>
w:
recirc_id=0,eth,tun_id=0x1c8,tun_src=1.1.2.92,tun_dst=1.1.2.88,tun_tos=0,tun_flags=-df-csum-key,in_port=3,dl_type=0x
+Datapath actions: drop
+])
+
+OVS_VSWITCHD_STOP
+AT_CLEANUP
--
2.20.1
William Tu 于2020年3月26日周四 下午11:05写道：
>
> On Sun, Mar 22, 2020 at 10:42:16AM +0800, 贺鹏 wrote:
> &
if the tunnel is specified as "remote_ip=flow", we can try to generate
a megaflow
which ignores all source address, such as source mac, source IP address
in the outter header of the packet. This can reduce the number of
megaflows and avoid expensive upcall and improve the performance.
if the tunnel is specified as "ip_remote=flow", we can try to generate
a megaflow
which ignores all source address, such as source mac, source IP address
in the outter header of the packet. This can reduce the number of
megaflows and avoid expensive upcall and improve the performance.
if the tunnel is specified as "ip_remote=flow", we can try to generate
a megaflow
which ignores all source address, such as source mac, source IP address
in the outter header of the packet. This can reduce the number of
megaflows and avoid expensive upcalls and improve the performance.
Hi,
there is a potential memory leak in ovs-dpdk hw offload, when remove a
dpdk port in datapath, the dpif will call dpif_port_del and will
eventually remove the netdev
from the map *port_to_netdev* (in netdev-offload). Meanwhile, a
resulted datapath reconfiguration will flush all the marked
Hi,
I found a potential memory leak in ovs-dpdk hw offload, when remove a
dpdk port in datapath,
the dpif will call dpif_port_del and will eventually remove the netdev
from the map *port_to_netdev* (in netdev-offload). Meanwhile, a
resulted datapath reconfiguration will flush all the marked flows
Hi,
I think the holding of dp_netdev_mutex lock can be removed in the
dpif_netdev_wait, as in dpif_netdev_run, the code does not hold the
dp_netdev_mutex lock, just the dp->port_mutex lock.
So I am curious why the code here holds the dp_netdev_mutex lock. If
any one knows it, I will appreciate
Got it.
You're correct.
Eli Britstein 于2019年12月9日周一 下午3:21写道：
>
>
> On 12/9/2019 9:15 AM, 贺鹏 wrote:
> > Hi,
> >
> >
> > cmap support multiple readers and one writer.
> > since all write operations are performed in the offload thread,
> > why
Hi,
cmap support multiple readers and one writer.
since all write operations are performed in the offload thread,
why need a mutex here? Maybe I miss some patches.
Eli Britstein 于2019年12月8日周日 下午9:23写道：
>
> Flow deletion and dumping for statistics collection are called from
> different
58 matches
Mail list logo
