On Wed, 22 May 2019 11:25:02 +0000, Boris Pismenny wrote: > > +Performance metrics > > +=================== > > + > > +TLS offload can be characterized by the following basic metrics: > > + > > + * max connection count > > + * connection installation rate > > + * connection installation latency > > + * total cryptographic performance > > + > > +Note that each TCP connection requires a TLS session in both directions, > > +the performance may be reported treating each direction separately. > > + > > +Max connection count > > +-------------------- > > + > > +The number of connections device can support can be exposed via > > +``devlink resource`` API. > > This is future changes, let's document when we implement this.
In what sense? The devlink resource API exists today, and doesn't require any infrastructure changes to report TLS table occupancy. I think it's a good idea to point driver authors at this existing infrastructure so they don't invent their own. Even if no driver today implements it. > > +Known bugs > > +========== > > + > > +skb_orphan() leaks clear text > > +----------------------------- > > + > > +Currently drivers depend on the :c:member:`sk` member of > > +:c:type:`struct sk_buff <sk_buff>` to identify segments requiring > > +encryption. Any operation which removes or does not preserve the socket > > +association such as :c:func:`skb_orphan` or :c:func:`skb_clone` > > +will cause the driver to miss the packets and lead to clear text leaks. > > + > > +Redirects leak clear text > > +------------------------- > > + > > +In the RX direction, if segment has already been decrypted by the device > > +and it gets redirected or mirrored - clear text will be transmitted out. > > Not sure if it is a bug or a feature as it needs administrator > intervention ;) Right, I'm not loosing that much sleep over this one :) > Overall, looks good to me. > Acked-by: Boris Pismenny <bor...@mellanox.com> Thank you!!
