> 2019/02/24 14:33、Vakul Garg <vakul.g...@nxp.com>のメール: > > > >> -----Original Message----- >> From: Hayakawa Yutaro <yhayakawa3720subscr...@gmail.com> >> Sent: Sunday, February 24, 2019 11:01 AM >> To: Vakul Garg <vakul.g...@nxp.com> >> Cc: netdev@vger.kernel.org >> Subject: Re: kTLS getsockopt TLS_RX support >> >> >>> 2019/02/24 10:50、Vakul Garg <vakul.g...@nxp.com>のメール: >>> >>> >>> >>>> -----Original Message----- >>>> From: netdev-ow...@vger.kernel.org <netdev-ow...@vger.kernel.org> >> On >>>> Behalf Of Hayakawa Yutaro >>>> Sent: Saturday, February 23, 2019 10:59 PM >>>> To: netdev@vger.kernel.org >>>> Subject: kTLS getsockopt TLS_RX support >>>> >>>> Hello, >>>> >>>> While trying the kTLS, I found out that currently, there is no >>>> support for kTLS getsockopt TLS_RX which extracts receive side crypto >>>> information from kTLS socket. Since setting crypto information for RX >>>> side is supported, I felt wonder why it is not supported. >>>> >>>> Is there any particular reason for it? >>> >>> What use case do you have in mind? >>> Why give back state of record layer which also contains (record sequence >> number) to user space? >> >> I’d like to checkpoint/restore the TLS session in conjunction with >> TCP_REPAIR. >> >> When we checkpoint the kTLS session, we need to pick the record sequence >> number or any other session information from kernel. For TX side, it is >> already supported (getsockopt TLS_TX), so I’m wondering why RX side is >> missing. >> >> Is there any technical difficulty or it will never supported in future? > > Don't think so. > Will you submit a patch?
Since I am one of the beginner user of kTLS, I don’t have much knowledge about the internal, but I have my own patch. I can test and submit it to here. Yutaro > >> Regards, >> Yutaro >> >>> >>>> >>>> Regards, >>>> Yutaro
