On Tue, 8 Nov 2022 09:36:01 +0100 Wilczynski, Michal wrote:

quoted

On 11/7/2022 7:31 PM, Jakub Kicinski wrote:  

quoted

You can't reply to email and then immediately post a new version :/
How am I supposed to have a conversation with you? Extremely annoying.  

I'm sorry if you find this annoying, however I can't see any harm here ?
I fixed some legit issues that you've pointed in v9, wrote some
documentation and basically said, "I wrote some documentation in
the next patchset, is it enough ?". I think it's better to get feedback
for smaller commits faster, this way I send the updated patchset
quickly.

Perhaps spending some time reading the list would help you understand
what normal development upstream looks like. Posting the N + 1 version
of a patch set and then replying to comments on version N is confusing
because it's impossible to decide where the conversation is taking
place. Should I reply to you on version N or reply to N + 1 even tho
there I can't quote your reply. And will the maintainer who's applying
the patches understand that N + 1 got rejected if the discussion is
happening under the thread of version N?

Perhaps one has to read the list to appreciate the challenges involved.

quoted

quoted

I'm tossing v10 from patchwork, and v11 better come with the docs :/  

I will however create a new devlink-rate.rst file if you insist.

There is however a mention about rate-object management in
devlink-port.rst. Would it be okay to extend devlink-por.rstt with new
attributes tx_priority, tx_weight instead of creating a new
devlink-rate.rst ?

Sounds good, but please make sure you describe the interaction between
the params and the algorithm. We don't have a SW implementation like we
have for qdiscs here, and we don't want each vendor to be coming up
with their own interpretation of the arguments. So we need solid docs,
and some pseudo code to describe the behavior, perhaps?

Let me ask some extra questions on the doc.