On 22.05.2016 09:44, Michael S. Tsirkin wrote:
> On Sat, May 21, 2016 at 03:02:30AM +0200, Hannes Frederic Sowa wrote:
>> Hello,
>>
>> On 18.05.2016 18:06, Tom Herbert wrote:
>>> In several gso_segment functions there are checks of gso_type against
>>> a seemingly arbitrary list of SKB_GSO_*
On Wed, May 18, 2016 at 09:06:09AM -0700, Tom Herbert wrote:
> In several gso_segment functions there are checks of gso_type against
> a seemingly arbitrary list of SKB_GSO_* flags. This seems like an
> attempt to identify unsupported GSO types, but since the stack is
> the one that set these GSO
On Sat, May 21, 2016 at 03:02:30AM +0200, Hannes Frederic Sowa wrote:
> Hello,
>
> On 18.05.2016 18:06, Tom Herbert wrote:
> > In several gso_segment functions there are checks of gso_type against
> > a seemingly arbitrary list of SKB_GSO_* flags. This seems like an
> > attempt to identify
On Fri, May 20, 2016 at 6:02 PM, Hannes Frederic Sowa
wrote:
> Hello,
>
> On 18.05.2016 18:06, Tom Herbert wrote:
>> In several gso_segment functions there are checks of gso_type against
>> a seemingly arbitrary list of SKB_GSO_* flags. This seems like an
>> attempt to
Hello,
On 18.05.2016 18:06, Tom Herbert wrote:
> In several gso_segment functions there are checks of gso_type against
> a seemingly arbitrary list of SKB_GSO_* flags. This seems like an
> attempt to identify unsupported GSO types, but since the stack is
> the one that set these GSO types in the
In several gso_segment functions there are checks of gso_type against
a seemingly arbitrary list of SKB_GSO_* flags. This seems like an
attempt to identify unsupported GSO types, but since the stack is
the one that set these GSO types in the first place this seems
unnecessary to do. If a