search for: seqpacket

...rote: > On Fri, Sep 01, 2023 at 02:45:14PM +0200, Stefano Garzarella wrote: > > On Tue, Aug 29, 2023 at 09:29:45PM +0000, Bobby Eshleman wrote: > > > This adds support for datagrams to the virtio-vsock device. > > > > > > virtio-vsock already supports stream and seqpacket types. The existing > > > message types and header fields are extended to support datagrams. > > > Semantic differences between the flow types are stated, as well as any > > > additional requirements for devices and drivers implementing this > > > feature. > &...

...rote: > On Fri, Sep 01, 2023 at 02:45:14PM +0200, Stefano Garzarella wrote: > > On Tue, Aug 29, 2023 at 09:29:45PM +0000, Bobby Eshleman wrote: > > > This adds support for datagrams to the virtio-vsock device. > > > > > > virtio-vsock already supports stream and seqpacket types. The existing > > > message types and header fields are extended to support datagrams. > > > Semantic differences between the flow types are stated, as well as any > > > additional requirements for devices and drivers implementing this > > > feature. > &...

...:35PM -0400, Michael S. Tsirkin wrote: > > > > On Tue, Aug 29, 2023 at 09:29:45PM +0000, Bobby Eshleman wrote: > > > > > This adds support for datagrams to the virtio-vsock device. > > > > > > > > > > virtio-vsock already supports stream and seqpacket types. The existing > > > > > message types and header fields are extended to support datagrams. > > > > > Semantic differences between the flow types are stated, as well as any > > > > > additional requirements for devices and drivers implementing this...

...:35PM -0400, Michael S. Tsirkin wrote: > > > > On Tue, Aug 29, 2023 at 09:29:45PM +0000, Bobby Eshleman wrote: > > > > > This adds support for datagrams to the virtio-vsock device. > > > > > > > > > > virtio-vsock already supports stream and seqpacket types. The existing > > > > > message types and header fields are extended to support datagrams. > > > > > Semantic differences between the flow types are stated, as well as any > > > > > additional requirements for devices and drivers implementing this...

...gt; > > > > > On Tue, Aug 29, 2023 at 09:29:45PM +0000, Bobby Eshleman wrote: > > > > > > > This adds support for datagrams to the virtio-vsock device. > > > > > > > > > > > > > > virtio-vsock already supports stream and seqpacket types. The existing > > > > > > > message types and header fields are extended to support datagrams. > > > > > > > Semantic differences between the flow types are stated, as well as any > > > > > > > additional requirements for devices...

...ock, struct msghdr *msg, >>> ??????????? err = total_written; >>> ????} >>> out: >>> +??? if (sk->sk_type == SOCK_STREAM) >>> +??????? err = sk_stream_error(sk, msg->msg_flags, err); >> >> Do you know why we don't need this for SOCK_SEQPACKET and SOCK_DGRAM? > >Yes, here is my explanation: > >This function checks that input error is SIGPIPE, and if so it sends SIGPIPE to the 'current' thread >(except case when MSG_NOSIGNAL flag is set). This behaviour is described in POSIX: > >Page 367 (description of define...

...? err = total_written; >>>>> ????} >>>>> out: >>>>> +??? if (sk->sk_type == SOCK_STREAM) >>>>> +??????? err = sk_stream_error(sk, msg->msg_flags, err); >>>> >>>> Do you know why we don't need this for SOCK_SEQPACKET and SOCK_DGRAM? >>> >>> Yes, here is my explanation: >>> >>> This function checks that input error is SIGPIPE, and if so it sends SIGPIPE to the 'current' thread >>> (except case when MSG_NOSIGNAL flag is set). This behaviour is described in POSI...

...? err = total_written; >>>>> ????} >>>>> out: >>>>> +??? if (sk->sk_type == SOCK_STREAM) >>>>> +??????? err = sk_stream_error(sk, msg->msg_flags, err); >>>> >>>> Do you know why we don't need this for SOCK_SEQPACKET and SOCK_DGRAM? >>> >>> Yes, here is my explanation: >>> >>> This function checks that input error is SIGPIPE, and if so it sends SIGPIPE to the 'current' thread >>> (except case when MSG_NOSIGNAL flag is set). This behaviour is described in POSI...

...gt; ????} >>>>>>> out: >>>>>>> +??? if (sk->sk_type == SOCK_STREAM) >>>>>>> +??????? err = sk_stream_error(sk, msg->msg_flags, err); >>>>>> >>>>>> Do you know why we don't need this for SOCK_SEQPACKET and SOCK_DGRAM? >>>>> >>>>> Yes, here is my explanation: >>>>> >>>>> This function checks that input error is SIGPIPE, and if so it sends SIGPIPE to the 'current' thread >>>>> (except case when MSG_NOSIGNAL flag is s...

...pf: rename vsock_dgram_* -> vsock_* > - vsock/bpf: change sk_psock_{get,put} and {lock,release}_sock() order > to minimize slock hold time > - vsock/bpf: use "new style" wait > - vsock/bpf: fix bug in wait log > - vsock/bpf: add check that recvmsg sk_type is one dgram, seqpacket, or > stream. Return error if not one of the three. > - virtio/vsock: comment __skb_recv_datagram() usage > - virtio/vsock: do not init copied in read_skb() > - vsock/bpf: add ifdef guard around struct proto in dgram_recvmsg() > - selftests/bpf: add vsock loopback config for aarch...

...EATS ------- * We're currently hooked into too many socket calls. We should be able to reduce the number of hooks to 3 (__sock_create(), sys_connect(), sys_bind()). * Our 'hw_socket' component should be folded into a netdev so we can leverage NAPI. * We don't handle SOCK_SEQPACKET, SOCK_RAW, SOCK_RDM, or SOCK_PACKET sockets. * We don't currently have support for /proc/net. Our current plan is to add '/proc/net/hwsock' (filename TBD) and add support for these sockets to the net-tools packages (netstat & friends), rather than muck around with plumbin...

...EATS ------- * We're currently hooked into too many socket calls. We should be able to reduce the number of hooks to 3 (__sock_create(), sys_connect(), sys_bind()). * Our 'hw_socket' component should be folded into a netdev so we can leverage NAPI. * We don't handle SOCK_SEQPACKET, SOCK_RAW, SOCK_RDM, or SOCK_PACKET sockets. * We don't currently have support for /proc/net. Our current plan is to add '/proc/net/hwsock' (filename TBD) and add support for these sockets to the net-tools packages (netstat & friends), rather than muck around with plumbin...