Project

General

Profile

Bug #52739

msg/async/ProtocalV2: recv_stamp of a message is set to a wrong value

Added by dongdong tao over 2 years ago. Updated 10 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
% Done:

100%

Source:
Tags:
backport_processed
Backport:
octopus,pacific
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(RADOS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

ProtocalV2 sets the recv_stamp after the message is throttled and received completely.

This is wrong because it was supposed to be a timestamp indicating the messenger started to receive the message.

This will cause the Ceph Daemons won't be able to take account of the time that spent in messenger level
when they calculate the request latency.

And also some of the latency related perf counters will not include the time spent in messenger level, which will
bring troubles when diagnosing network-related performance issues.

Note that this is only for V2, V1 has correctly set this value .


Related issues

Copied to RADOS - Backport #52842: octopus: msg/async/ProtocalV2: recv_stamp of a message is set to a wrong value Rejected
Copied to RADOS - Backport #52843: pacific: msg/async/ProtocalV2: recv_stamp of a message is set to a wrong value Resolved

History

#2 Updated by Kefu Chai over 2 years ago

  • Status changed from New to Fix Under Review
  • Pull request ID set to 43307

#3 Updated by Dan Hill over 2 years ago

  • Backport set to octopus,pacific

#4 Updated by Kefu Chai over 2 years ago

  • Status changed from Fix Under Review to Pending Backport

#5 Updated by Backport Bot over 2 years ago

  • Copied to Backport #52842: octopus: msg/async/ProtocalV2: recv_stamp of a message is set to a wrong value added

#6 Updated by Backport Bot over 2 years ago

  • Copied to Backport #52843: pacific: msg/async/ProtocalV2: recv_stamp of a message is set to a wrong value added

#7 Updated by Backport Bot over 1 year ago

  • Tags set to backport_processed

#8 Updated by Konstantin Shalygin 10 months ago

  • Status changed from Pending Backport to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF