Searched hist:"6 a35ddc5445a8291ced6247a67977e110275acde" (Results 1 – 9 of 9) sorted by relevance
| /openbmc/linux/drivers/net/ethernet/netronome/nfp/crypto/ |
| H A D | fw.h | diff 6a35ddc5445a8291ced6247a67977e110275acde Tue Dec 17 16:12:02 CST 2019 Jakub Kicinski <jakub.kicinski@netronome.com> nfp: tls: implement the stream sync RX resync
The simple RX resync strategy controlled by the kernel does not
guarantee as good results as if the device helps by detecting
the potential record boundaries and keeping track of them.
We've called this strategy stream scan in the tls-offload doc.
Implement this strategy for the NFP. The device sends a request
for record boundary confirmation, which is then recorded in
per-TLS socket state and responded to once record is reached.
Because the device keeps track of records passing after the
request was sent the response is not as latency sensitive as
when kernel just tries to tell the device the information
about the next record.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | crypto.h | diff 6a35ddc5445a8291ced6247a67977e110275acde Tue Dec 17 16:12:02 CST 2019 Jakub Kicinski <jakub.kicinski@netronome.com> nfp: tls: implement the stream sync RX resync
The simple RX resync strategy controlled by the kernel does not
guarantee as good results as if the device helps by detecting
the potential record boundaries and keeping track of them.
We've called this strategy stream scan in the tls-offload doc.
Implement this strategy for the NFP. The device sends a request
for record boundary confirmation, which is then recorded in
per-TLS socket state and responded to once record is reached.
Because the device keeps track of records passing after the
request was sent the response is not as latency sensitive as
when kernel just tries to tell the device the information
about the next record.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | tls.c | diff 6a35ddc5445a8291ced6247a67977e110275acde Tue Dec 17 16:12:02 CST 2019 Jakub Kicinski <jakub.kicinski@netronome.com> nfp: tls: implement the stream sync RX resync
The simple RX resync strategy controlled by the kernel does not
guarantee as good results as if the device helps by detecting
the potential record boundaries and keeping track of them.
We've called this strategy stream scan in the tls-offload doc.
Implement this strategy for the NFP. The device sends a request
for record boundary confirmation, which is then recorded in
per-TLS socket state and responded to once record is reached.
Because the device keeps track of records passing after the
request was sent the response is not as latency sensitive as
when kernel just tries to tell the device the information
about the next record.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| /openbmc/linux/drivers/net/ethernet/netronome/nfp/ |
| H A D | ccm.h | diff 6a35ddc5445a8291ced6247a67977e110275acde Tue Dec 17 16:12:02 CST 2019 Jakub Kicinski <jakub.kicinski@netronome.com> nfp: tls: implement the stream sync RX resync
The simple RX resync strategy controlled by the kernel does not
guarantee as good results as if the device helps by detecting
the potential record boundaries and keeping track of them.
We've called this strategy stream scan in the tls-offload doc.
Implement this strategy for the NFP. The device sends a request
for record boundary confirmation, which is then recorded in
per-TLS socket state and responded to once record is reached.
Because the device keeps track of records passing after the
request was sent the response is not as latency sensitive as
when kernel just tries to tell the device the information
about the next record.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | nfp_net_ctrl.c | diff 6a35ddc5445a8291ced6247a67977e110275acde Tue Dec 17 16:12:02 CST 2019 Jakub Kicinski <jakub.kicinski@netronome.com> nfp: tls: implement the stream sync RX resync
The simple RX resync strategy controlled by the kernel does not
guarantee as good results as if the device helps by detecting
the potential record boundaries and keeping track of them.
We've called this strategy stream scan in the tls-offload doc.
Implement this strategy for the NFP. The device sends a request
for record boundary confirmation, which is then recorded in
per-TLS socket state and responded to once record is reached.
Because the device keeps track of records passing after the
request was sent the response is not as latency sensitive as
when kernel just tries to tell the device the information
about the next record.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | nfp_net_ctrl.h | diff 6a35ddc5445a8291ced6247a67977e110275acde Tue Dec 17 16:12:02 CST 2019 Jakub Kicinski <jakub.kicinski@netronome.com> nfp: tls: implement the stream sync RX resync
The simple RX resync strategy controlled by the kernel does not
guarantee as good results as if the device helps by detecting
the potential record boundaries and keeping track of them.
We've called this strategy stream scan in the tls-offload doc.
Implement this strategy for the NFP. The device sends a request
for record boundary confirmation, which is then recorded in
per-TLS socket state and responded to once record is reached.
Because the device keeps track of records passing after the
request was sent the response is not as latency sensitive as
when kernel just tries to tell the device the information
about the next record.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | nfp_net.h | diff 6a35ddc5445a8291ced6247a67977e110275acde Tue Dec 17 16:12:02 CST 2019 Jakub Kicinski <jakub.kicinski@netronome.com> nfp: tls: implement the stream sync RX resync
The simple RX resync strategy controlled by the kernel does not
guarantee as good results as if the device helps by detecting
the potential record boundaries and keeping track of them.
We've called this strategy stream scan in the tls-offload doc.
Implement this strategy for the NFP. The device sends a request
for record boundary confirmation, which is then recorded in
per-TLS socket state and responded to once record is reached.
Because the device keeps track of records passing after the
request was sent the response is not as latency sensitive as
when kernel just tries to tell the device the information
about the next record.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | nfp_net_ethtool.c | diff 6a35ddc5445a8291ced6247a67977e110275acde Tue Dec 17 16:12:02 CST 2019 Jakub Kicinski <jakub.kicinski@netronome.com> nfp: tls: implement the stream sync RX resync
The simple RX resync strategy controlled by the kernel does not
guarantee as good results as if the device helps by detecting
the potential record boundaries and keeping track of them.
We've called this strategy stream scan in the tls-offload doc.
Implement this strategy for the NFP. The device sends a request
for record boundary confirmation, which is then recorded in
per-TLS socket state and responded to once record is reached.
Because the device keeps track of records passing after the
request was sent the response is not as latency sensitive as
when kernel just tries to tell the device the information
about the next record.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| H A D | nfp_net_common.c | diff 6a35ddc5445a8291ced6247a67977e110275acde Tue Dec 17 16:12:02 CST 2019 Jakub Kicinski <jakub.kicinski@netronome.com> nfp: tls: implement the stream sync RX resync
The simple RX resync strategy controlled by the kernel does not
guarantee as good results as if the device helps by detecting
the potential record boundaries and keeping track of them.
We've called this strategy stream scan in the tls-offload doc.
Implement this strategy for the NFP. The device sends a request
for record boundary confirmation, which is then recorded in
per-TLS socket state and responded to once record is reached.
Because the device keeps track of records passing after the
request was sent the response is not as latency sensitive as
when kernel just tries to tell the device the information
about the next record.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|